Re: Proposal regarding 1.6

I have been thinking a bit regarding ways forward. In particular the financial rewrite never seems to go the way I would like it to.

We spoke a bit about this over PM last week. Maybe we can use this (or a new) thread to define what it means to you? I'm not really clear on what the term "financial rewrite" really means to you. Although I do have ideas about breaking down the scope of rewriting the remaining SQL Ledger code into a larger number of smaller rewrites. Before we can do that, though, I think we have a number of areas where we should put requirements/design/workflow in place. I'm thinking about things like these:

- Document workflow: Create -> Save -> [ Edit -> Return to Save ] -> Post -> Reproduce [ -> Copy to new ] [ -> Schedule ]

- Rounding

- Subcent prices on anything that's not in the ledger (parts prices?)

stuff like that.

We have at least one important feature slated for 1.6, and that is the multi-currency improvements Erik has been working on. I would like to suggest we do one other thing as well, namely finish App::LedgerSMB::Admin and App::LedgerSMB::Admin::Web, and use these to replace the current setup.pl.

It's my understanding that these will serve a much broader range of functionalities than setup.pl, am I correct? More like a toolset for managing companies within a PostgreSQL cluster (i.e. multiple databases)? Is there anything more to say about it than that?

Work that is left to do here is to add a setup wizard and add user management functions to the web interface. A major advantage would be an ability to manage multiple LedgerSMB instances from one console, better command line management, and restful interfaces for core administrative functions.

Also, version 1.x of the admin interface uses jquery and templates in a fairly old-fashioned way. We may want to move to dojo there and start a 2.x branch of this.

Sounds good, but I think that creating services early on allows easier dojoification, because Dojo applications typically benefit from a well structured service infrastructure on the server. Having a full-scale web app based on templates before going Dojo will be a lot of effort wasted on the 'traditional' webapp.

That would allow us to remove

LedgerSMB::Darabase
LdgerSMB::Scripts::setup
and maybe a little more.

Removal is generally good. There's one important question though: should we move these into our tree or not? As we factorize many components, it might become harder for people to install the factored-out dependencies. While this may or may not be the case, I think it's something to think about long and hard before we throw up road blocks to installing LedgerSMB.

I would also like to suggest we look closely at one of the following areas (would be interested in hearing where folks largest frustrations are here) in terms of UX, web services, and the like:

chart of accounts, or contact management.

Any thoughts on prioritiing these?

If I can have a vote: Please start with services for contact management. That'll allow easier Dojoification of the contact management screens, which hopefully will help with the clarification of them.

Bye,

Erik.

http://efficito.com -- Hosted accounting and ERP.

Robust and Flexible. No vendor lock-in.