Re: Proposal regarding 1.6

On Mon, Oct 12, 2015 at 8:09 PM, Erik Huelsmann <..hidden..> wrote:

[ snip ]

Summarizing most of the discussion:

1. There's a lot we can still do in 1.x, e.g.
a. Better installation experience
b. Better admin tools
c. Disentangle tightly coupled code like 'ship to' and 'e-mail'
d. True multi currency
e. Much, much more QA and automated testing
2. As a mental model, 2.x might help us discover where we can do - even within 1.x
3. Before we can make some of the steps mentioned above, we'll need to have in-depth discussion on the goals and the design, because the low-hanging fruits have largely been reaped
4. The general tool to help disentangling the Perl code *and* to improve user experience seems to be through Dojo/browser-client-side solutions

Agreed. I also think that the admin tools integration will provide a platform for looking at how we want to go about #3 but frankly that's a discussion for another time or at least another thread. (I think another time because depending on how it goes, it may not be worth having until the admin tools are integrated).

With respect to the last point, as you know, I'm trying to retrofit a Dojo interface on top of some existing code which I taught to "speak" JSON. My journey shows that this is a far from ideal situation and that it's hard to achieve good results. This experience by itself is enough evidence - I would say (and I hope you do too, when I finally commit the results) - to start working on a service based architecture as soon as 1.5 gets out the door.

At that point we immediatly arrive at point (3): designing a URL space for our services is one of the discussions we still need to have and *that* is exactly the reason I'm working off of the existing code base molding it into something of which Dojo thinks it's a REST service...

This is actually why I want to integrate the admin tools, because they do have a url space and if we like that approach we can take it for the rest, pun intended. And if it works well, the next obvious one would be the menu and the new account screen (coa). If we get these things done for the complex parts of our rewritten code then we have hopefully both simplified it and created a way forward on the remainder.

I'm thinking of ways forward without loosing focus on actually getting forward. How about listing the topics that we're currently running into and discussing those one-by-one in order of most to least important (blocking work)? It'd be nice if we could store the result of the discussion on the ledgersmb.org site as a policy or design document.

I think the first question is how we get to a point where we can talk about the best way to really talking about the way forward for the large, intertwined chunks.

To kick off such a list, I personally have the following issues which need design or an approach discussion:
- Service URL space, most notably dealing with tables which have composite primary keys

I am not sure db design and url space need to be tightly coupled here. Where we have composite primary keys we always have a surrogate secondary key which we can use (and which we do use anyway for foreign keys). I don't think tables are necessarily resource collections from the app perspective. When we label something as the db in the table, we are saying something about the nature of the data. We aren't necessarily saying anything about access to that data. That's a decision we made early on, to define primary keys by nature rather than by use and it leads to clearer db design.

- Framework for writing tests for services
- Framework for writing tests for browser-based functionalities

Do you have others?

There was some discussion between the two of us a few months back about cash reporting and the Cashflow Statement though that "simply" marking accounts as "cash related" didn't work.

The problem with the cash flow statement is different. It is because despite the name it is actually an accrual report, but the sectioning is different than what we support. So supporting that report requires additional categorization on accounts.

I was referring to this: http://www.accountingcoach.com/cash-flow-statement/explanation

Ok I was formerly confused about this report too.

But the problem is not cash basis handling, but account categorization there. The cash flow statement there, it turns out, i actually an accrual-basis report, but it uses account classifications which are orthogonal to those of the income statement and balance sheet. In other words, to support it, we need a second set of account classifications. I just haven't gotten around to adding it.

What I remember is that it *mostly* worked, but the problem came when assets were sold off at their end-of-life. What I remember is that the cash flow of the end-of-life sale is to be reported as gains/losses from investment activities, which was a problem given that the regular movements on the investment section (depreciation) is a loss from operational activities. To understand the true problem again, I/we'll have to go through the entire cycle of creating a mapping of accounts to a cashflow statement again.

Yeah, I think you are thinking of the cash-basis income statement? I suspect things may have different names in different places?

2. We would have much better performance and clearer code if the journal tables were unified or split off in better ways.

Agreed. Although this is a change with widespread consequences in the Perl code, it's a pretty minor change in the sql code, I think (yes, the three tables are union-queried all over the place, but if they are mostly replaced by a single table listing all transactions, many uses of the ar and ap tables can simply be dropped.)

Well, in the end, not addressing with this proposal how and when we get there. I think there are a lot of things to think about such as whether we need to move code anyway onto Dancer, and if we need to do that, what the best way forward on that is. So after our previous conversation I am not sure we are in a place yet to map out exactly what needs to be done to rewrite the financial code. I do however think important steps can be taken in 1.x in this direction.

Ok. I don't know the exact steps either, but one of the things that we *will* need is disentangling contrived code and update paths -- we both agree about that. Probably, when that's done, it'll become much clearer what actually needs to happen.

[ snip violent agreement ]

[ snip about admin tool ]

It also occurs to me that if the admin tool is sufficiently service-oriented, then the installation wizard could be a _javascript_ app bundled with the main program.

There is one limitation that has occurred to me and that is that the current approach returns html in most cases rather than using services and dojo. Although I think we support services for xhr calls, that doesn't do much for things like lwp. If we do a clean service/dojo API though then that goes away. I think getting this right would be a good step towards getting started on other service areas.

Actually, the pricematrix page that I'm now working on returns only minimal HTML: the widgets are all loaded and instantiated by Dojo. This all happens through resource and service URLs, meaning that the "base" URL space will see minimal functionality anymore.

From what I could determine, that's how GitLab (I'm using GitLab for one of the sites I'm an admin of, as you know) seems to work (although I have no idea if it uses Dojo for its widgets).

Going over the difficulties regarding CGI::Simple in this regard (and not supporting using query strings in put operations) I think we need to think about a good framework for URL mapping and services going forward and I am not terribly interested in creating a new one based on what we have.

So I guess that's why I want to start with a tool we already have and get that integrated.

[ snip more violent agreement ]

Thanks for posting your thoughts and thanks for the discussion. I know we need a lot more of it, but the form that this discussion has taken is a good and effective one, I think.

One of the things that I'm wondering about now though is how to keep it up and jump to the next step, keeping momentum now that we seem to have it?

Ok, so let's start out with an interesting question which seems like it is in a very different direction but is important for getting the admin tools up to where they need to be for this:

What do we expect a command line to add a user would look like?

Here is my proposal

lsmb_add_user --first-name Alfred --last-name King --empnum E-1000 --salutation Mr --dob 1960-01-01 --taxnum 123-34-5555 --roles ap_all,gl_all,ar_all

Best Wishes

Chris Travers

--
Bye,

Erik.

http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.

------------------------------------------------------------------------------

_______________________________________________
Ledger-smb-devel mailing list
..hidden..
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

Best Wishes,

Chris Travers

Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor lock-in.

http://www.efficito.com/learn_more