| *** bkuhn has quit IRC | 00:24 | |
| *** nesciens has joined #npoacct | 01:37 | |
| *** garrison has quit IRC | 01:56 | |
| *** garrison has joined #npoacct | 02:37 | |
| *** nesciens has quit IRC | 03:57 | |
| *** nesciens has joined #npoacct | 10:44 | |
| *** bkuhn has joined #npoacct | 12:42 | |
| *** bkuhn is now known as bkuhnIdle | 12:45 | |
| *** bkuhnIdle is now known as bkuhn | 13:55 | |
| bkuhn | greetings, joar, how's it going? | 14:20 |
|---|---|---|
| joar | greetings bkuhn | 15:13 |
| joar | feeling better | 15:13 |
| bkuhn | That's good! | 15:14 |
| joar | bkuhn: that's a good email | 15:51 |
| bkuhn | the one to ERPNext, you mean? | 15:51 |
| joar | yes | 15:53 |
| joar | glad it got resolved | 15:53 |
| joar | bkuhn: Looking at the current codebase, it seems that the licensing issue has been resolved, would you agree? | 15:57 |
| bkuhn | I haven't seen the responses, I'm working on some other matters. URL? | 15:57 |
| joar | https://groups.google.com/d/msg/erpnext-developer-forum/jfsURU8Ew9A/Ejz_J_otzDQJ | 15:58 |
| bkuhn | It's mostly resolved, I have a tweak to suggest. | 15:59 |
| bkuhn | I'll send it later. | 15:59 |
| joar | ok | 15:59 |
| bkuhn | joar: you can proceed evaluating other parts of ERPNext if you want | 15:59 |
| joar | Yeah, that was my intention | 16:00 |
| bkuhn | thanks. | 16:00 |
| joar | bkuhn: will you be busy all week? | 16:37 |
| bkuhn | I mean, yes, of course, but I that might include working with you if you need something. :) | 16:37 |
| joar | yeah :) | 16:37 |
| joar | I'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 |
| joar | I've asked for help with OFBiz, ERP5. | 16:38 |
| bkuhn | joar: That's fine. | 16:45 |
| bkuhn | I'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 |
| bkuhn | So, 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 IRC | 17:18 | |
| joar | bkuhn: I think building an application will be 'easier' and perhaps less mentally challenging than analyzing existing applications. | 17:39 |
| joar | The analysis usually has a lot of context switches for me. | 17:40 |
| bkuhn | Are you saying, building an application as opposed to building an API implementation? | 17:40 |
| bkuhn | Or just developing as opposed to evaluating? | 17:40 |
| joar | I understand that all of these people have started their own projects instead of adapting a preexisting project. | 17:41 |
| bkuhn | True, but I don't think I'm following your argument. | 17:42 |
| joar | Building an API has challenges similar to building an application, since an application is just another type of "API". | 17:42 |
| joar | I think the application/API building will be easier to do than the actual evaluation. | 17:43 |
| joar | but I also think the evaluation is a good thing, as it provides some insights in how these applications are built. | 17:43 |
| bkuhn | Well, 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 |
| bkuhn | I know it's difficult, but we'll finish soon. | 17:44 |
| bkuhn | I realize we may not meet our deadline of this friday. | 17:44 |
| bkuhn | but we'll get there. | 17:44 |
| joar | I do not disagree with you, I'm just reflecting :) | 17:45 |
| joar | ERPNext seems to have an API | 17:49 |
| joar | I'm going to post to their list and ask them for help too. | 17:50 |
| bkuhn | ok. thanks! | 17:54 |
| bkuhn | I'm really interested, though, in an API that has the double-entry accounting data separated from the ERP functions. | 17:54 |
| bkuhn | I wonder if ERPNext has that. | 17:54 |
| joar | Added as FIXME under ERPNext | 17:56 |
| joar | ERPNext uses raw SQL statements. | 18:25 |
| joar | and unfortunately they do not filter their input. | 18:30 |
| joar | I see 2637 webnotes.conn.sql() function calls in total, and 192 of those are in the 'accounts' module. | 18:31 |
| joar | I'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 |
| joar | such as the DELETE FROM queries. | 18:41 |
| joar | bkuhn: ^^ | 18:43 |
| bkuhn | Thanks, sorry just saw this.... | 19:24 |
| bkuhn | and I have to go idle, will comment when I get back | 19:24 |
| joar | ok | 19:24 |
| *** bkuhn is now known as bkuhnIdle | 19:24 | |
| joar | s/traceback(1)/traceback(!)/ as traceback is usually something you don't want to provide to the world. | 19:25 |
| joar | at 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 bkuhn | 20:09 | |
| * bkuhn is back | 20:09 | |
| bkuhn | joar: 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 |
| bkuhn | You mentioned they had an API though, it is any good? | 20:09 |
| bkuhn | joar: 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 |
| joar | that sounds interesting | 20:21 |
| joar | bkuhn: and with API I think you mean a specification for an API, is that correct? | 20:21 |
| joar | right | 20:21 |
| joar | that's actually what you said. | 20:21 |
| bkuhn | Yes, kfogel's suggestion was we both specify and start implementing | 20:22 |
| bkuhn | basically, what I'm calling the "StorageAPI" | 20:22 |
| bkuhn | ... using ledger-cli as a backend | 20:22 |
| joar | that answered was I was wondering :) | 20:22 |
| bkuhn | and go around to other projects and shop it. | 20:22 |
| bkuhn | as well as trying to use it ourselves. | 20:22 |
| bkuhn | I think it's a good suggestion. | 20:22 |
| joar | good. yes. | 20:22 |
| bkuhn | I 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 |
| joar | that makes great sense, since there's so much variation and specialization in the accounting genre of software. | 20:24 |
| bkuhn | joar: 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 |
| joar | Yes | 20:27 |
| joar | certainly. | 20:27 |
| joar | and I feel that some of the applications (Kuali, OFBiz) seem to have modularity as a goal. | 20:27 |
| bkuhn | It might be worth looking closely at them to see, then, if it seems they have a double-entry accounting API. | 20:28 |
| joar | but 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 |
| joar | and Kuali is community-wise all but open. | 20:29 |
| joar | and also a JVM citizen. | 20:29 |
| bkuhn | Hrm. | 20:31 |
| bkuhn | kfogel suggested, which was also suggested on the mailing list, that a REST API would make sense. | 20:32 |
| joar | I also feel that is more appropriate. I also recall some discussions of flexibility in the transport used. | 20:32 |
| bkuhn | I 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 |
| bkuhn | And besides, we already have an NP-Complete problem we must face anyway, since automated Bank Reconciliation reduces to subset sum. :) | 20:33 |
| joar | I 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 |
| joar | We could look into other communication protocols if we decide to do that. | 20:37 |
| joar | REST API is straight-forward, so initially I think that might be the best idea. | 20:37 |
| joar | however, I'm going to return to the evaluations. | 20:44 |
| bkuhn | sure, thanks, that's the right thing for now. | 21:08 |
| joar | bkuhn: http://npoacct.sfconservancy.org/ExistingProjects/ERPNext/ updated! Please review | 21:22 |
| bkuhn | joar: thanks, I probably need to do it tomorrow though, anything urgent you want me to look at now? | 21:22 |
| joar | bkuhn: it's okay, tomorrow will be fine | 21:22 |
| bkuhn | Thanks. (Meanwhile, did you report the SQL injection bugs in their bugtracker_ | 21:22 |
| bkuhn | ) | 21:23 |
| joar | bkuhn: yes, https://github.com/webnotes/erpnext/issues/1075 | 21:23 |
| bkuhn | thanks | 21:23 |
| joar | bkuhn: Is the licensing issue with ERPNext "OK" but not optimal as of now? | 21:24 |
| bkuhn | joar: yes, and I think it will get to optimal. I'm going to offer them a merge request that further clarifies. | 21:25 |
| joar | In that case I'll move the ERPNext entry back in the list and mark it as filled out by me. | 21:25 |
| joar | good :) | 21:25 |
| paroneayea | oh my, REST API sounds pretty great. | 21:31 |
| bkuhn | It depends on what it does, of course. :) | 21:43 |
| joar | bkuhn: I propose for Bookyt to be dropped from the evaluation. | 21:59 |
| bkuhn | How come? | 21:59 |
| joar | I 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 code | 22:04 |
| joar | bkuhn: 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 |
| joar | I could also send the developer an email and ask for assistance. | 22:08 |
| joar | I will do that, send an email. | 22:11 |
| bkuhn | Yeah, that makes sense | 22:11 |
| bkuhn | if the developer wants to fill out the eval form themselves, great. | 22:12 |
| bkuhn | if not, we can ignore it | 22:12 |
| *** garrison has quit IRC | 22:17 | |
| joar | bkuhn: ok, sent | 22:18 |
| joar | bkuhn: I will sign off for today. Have a good night! | 22:20 |
| bkuhn | Sure!~ | 22:21 |
| bkuhn | Goodnight | 22:21 |
| *** nesciens has joined #npoacct | 23:08 | |
Generated by irclog2html.py 2.12.1 by Marius Gedminas - find it at mg.pov.lt!