Wednesday, 2013-11-20

*** bkuhn has quit IRC00:24
*** nesciens has joined #npoacct01:37
*** garrison has quit IRC01:56
*** garrison has joined #npoacct02:37
*** nesciens has quit IRC03:57
*** nesciens has joined #npoacct10:44
*** bkuhn has joined #npoacct12:42
*** bkuhn is now known as bkuhnIdle12:45
*** bkuhnIdle is now known as bkuhn13:55
bkuhngreetings, joar, how's it going?14:20
joargreetings bkuhn15:13
joarfeeling better15:13
bkuhnThat's good!15:14
joarbkuhn: that's a good email15:51
bkuhnthe one to ERPNext, you mean?15:51
joaryes15:53
joarglad it got resolved15:53
joarbkuhn: Looking at the current codebase, it seems that the licensing issue has been resolved, would you agree?15:57
bkuhnI haven't seen the responses, I'm working on some other matters.  URL?15:57
joarhttps://groups.google.com/d/msg/erpnext-developer-forum/jfsURU8Ew9A/Ejz_J_otzDQJ15:58
bkuhnIt's mostly resolved, I have a tweak to suggest.15:59
bkuhnI'll send it later.15:59
joarok15:59
bkuhnjoar: you can proceed evaluating other parts of ERPNext if you want15:59
joarYeah, that was my intention16:00
bkuhnthanks.16:00
joarbkuhn: will you be busy all week?16:37
bkuhnI mean, yes, of course, but I that might include working with you if you need something. :)16:37
joaryeah :)16:37
joarI'll look at ERPNext today. I'm not sure I will be able to fill out the entire templates for all the existing projects before friday though.16:38
joarI've asked for help with OFBiz, ERP5.16:38
bkuhnjoar: That's fine.16:45
bkuhnI've had a useful chat with Karl Fogel, Adam from Fractured Atlas and a few others about the project...16:45
bkuhn... and they had some ideas.  One point was that if we really find that none of these codebases have a clear API for double entry accounting part, that our big contribution might be to start with doing that REST API that's being discussed on the mailing list.17:01
bkuhnSo, it's worth finishing the evaluations, definitely, but perhaps we conclude that it doesn't make sense to try and build a whole application with the resources we have.17:02
*** nesciens has quit IRC17:18
joarbkuhn: I think building an application will be 'easier' and perhaps less mentally challenging than analyzing existing applications.17:39
joarThe analysis usually has a lot of context switches for me.17:40
bkuhnAre you saying, building an application as opposed to building an API implementation?17:40
bkuhnOr just developing as opposed to evaluating?17:40
joarI understand that all of these people have started their own projects instead of adapting a preexisting project.17:41
bkuhnTrue, but I don't think I'm following your argument.17:42
joarBuilding an API has challenges similar to building an application, since an application is just another type of "API".17:42
joarI think the application/API building will be easier to do than the actual evaluation.17:43
joarbut I also think the evaluation is a good thing, as it provides some insights in how these applications are built.17:43
bkuhnWell, as I said on the mailing list, we're looking for a diamond in the rough, and looking to avoid the mistakes of the past.  I think I said on the mailing list too that I think we won't find a codebase that can be adapted easily for non-profits.  But we did pledge to the community that we'd at least look at what is out there.17:44
bkuhnI know it's difficult, but we'll finish soon.17:44
bkuhnI realize we may not meet our deadline of this friday.17:44
bkuhnbut we'll get there.17:44
joarI do not disagree with you, I'm just reflecting :)17:45
joarERPNext seems to have an API17:49
joarI'm going to post to their list and ask them for help too.17:50
bkuhnok.  thanks!17:54
bkuhnI'm really interested, though, in an API that has the double-entry accounting data separated from the ERP functions.17:54
bkuhnI wonder if ERPNext has that.17:54
joarAdded as FIXME under ERPNext17:56
joarERPNext uses raw SQL statements.18:25
joarand unfortunately they do not filter their input.18:30
joarI see 2637 webnotes.conn.sql() function calls in total, and 192 of those are in the 'accounts' module.18:31
joarI've managed to cause a trivial SQL injection, just receiving a traceback(1) from the demo.erpnext.com server, I'm looking to see if they have covered up any holes in any of their queries.18:41
joarsuch as the DELETE FROM queries.18:41
joarbkuhn: ^^18:43
bkuhnThanks, sorry just saw this....19:24
bkuhnand I have to go idle, will comment when I get back19:24
joar ok19:24
*** bkuhn is now known as bkuhnIdle19:24
joars/traceback(1)/traceback(!)/ as traceback is usually something you don't want to provide to the world.19:25
joarat least not in production environments, and I just tried the same on wandborg.erpnext.com (my free trial) and it's the same.19:28
*** bkuhnIdle is now known as bkuhn20:09
* bkuhn is back20:09
bkuhnjoar: yikes.  That's really bad news.  We owe it to them to open a bug ticket on that, for sure....20:09
bkuhn .... but that's really troubling.20:09
bkuhnYou mentioned they had an API though, it is any good?20:09
bkuhnjoar: BTW, one idea I chatted with kfogel about yesterday is that we specify an API and encourage some of these projects to collaborate on its design and/or comment.20:11
joarthat sounds interesting20:21
joarbkuhn: and with API I think you mean a specification for an API, is that correct?20:21
joarright20:21
joarthat's actually what you said.20:21
bkuhnYes, kfogel's suggestion was we both specify and start implementing20:22
bkuhnbasically, what I'm calling the "StorageAPI"20:22
bkuhn... using ledger-cli as a backend20:22
joarthat answered was I was wondering :)20:22
bkuhnand go around to other projects and shop it.20:22
bkuhnas well as trying to use it ourselves.20:22
bkuhnI think it's a good suggestion.20:22
joargood. yes.20:22
bkuhnI want to finish our evaluations, for completeness, but I think kfogel convinced me that made sense (Along with discussions with the fellow from Fractured Atlas, who was suggesting something similar... he'd like to see a "toolkit" for building accounting applications)20:23
joarthat makes great sense, since there's so much variation and specialization in the accounting genre of software.20:24
bkuhnjoar: Do you agree that what we're finding so far in the evaluations is indicating that a failure of modular design is what's causing this "reinvent the wheel" syndrome?20:26
joarYes20:27
joarcertainly.20:27
joarand I feel that some of the applications (Kuali, OFBiz) seem to have modularity as a goal.20:27
bkuhnIt might be worth looking closely at them to see, then, if it seems they have a double-entry accounting API.20:28
joarbut I cannot see any of them succeeding at making an OPEN modular application. In the case of OFBiz it seems to be 'open' for modules within the application, and that means within the JVM.20:28
joarand Kuali is community-wise all but open.20:29
joarand also a JVM citizen.20:29
bkuhnHrm.20:31
bkuhnkfogel suggested, which was also suggested on the mailing list, that a REST API would make sense.20:32
joarI also feel that is more appropriate. I also recall some discussions of flexibility in the transport used.20:32
bkuhnI get Chris Travers' arguments of why it might be inefficient, but I always learned to never let code efficiency (other than actual algorithmic complexity of course) determine initial design .20:32
bkuhnAnd besides, we already have an NP-Complete problem we must face anyway, since automated Bank Reconciliation reduces to subset sum. :)20:33
joarI will take a look at the bank reconciliation when that time comes. I have no formal CS eductaion, so NP-complete translates to 'hard' for me :)20:35
joarWe could look into other communication protocols if we decide to do that.20:37
joarREST API is straight-forward, so initially I think that might be the best idea.20:37
joarhowever, I'm going to return to the evaluations.20:44
bkuhnsure, thanks, that's the right thing for now.21:08
joarbkuhn: http://npoacct.sfconservancy.org/ExistingProjects/ERPNext/ updated! Please review21:22
bkuhnjoar: thanks, I probably need to do it tomorrow though, anything urgent you want me to look at now?21:22
joarbkuhn: it's okay, tomorrow will be fine21:22
bkuhnThanks. (Meanwhile, did you report the SQL injection bugs in their bugtracker_21:22
bkuhn)21:23
joarbkuhn: yes, https://github.com/webnotes/erpnext/issues/107521:23
bkuhnthanks21:23
joarbkuhn: Is the licensing issue with ERPNext "OK" but not optimal as of now?21:24
bkuhnjoar: yes, and I think it will get to optimal.  I'm going to offer them a merge request that further clarifies.21:25
joarIn that case I'll move the ERPNext entry back in the list and mark it as filled out by me.21:25
joargood :)21:25
paroneayeaoh my, REST API sounds pretty great.21:31
bkuhnIt depends on what it does, of course. :)21:43
joarbkuhn: I propose for Bookyt to be dropped from the evaluation.21:59
bkuhnHow come?21:59
joarI do not think it has a reasonable chance to fit NPO accounting based on the evaluation template.22:01
joar.. and the features described in the source code22:04
joarbkuhn: I could set up a VM and install it for testing and fill out the evaluation template according to my findings there.22:06
joar.. the proposal was an effort to reduce the number of remaining projects to evaluate.22:07
joarI could also send the developer an email and ask for assistance.22:08
joarI will do that, send an email.22:11
bkuhnYeah, that makes sense22:11
bkuhnif the developer wants to fill out the eval form themselves, great.22:12
bkuhnif not, we can ignore it22:12
*** garrison has quit IRC22:17
joarbkuhn: ok, sent22:18
joarbkuhn: I will sign off for today. Have a good night!22:20
bkuhnSure!~22:21
bkuhnGoodnight22:21
*** nesciens has joined #npoacct23:08

Generated by irclog2html.py 2.12.1 by Marius Gedminas - find it at mg.pov.lt!