Re: Change management

On Tue, Aug 11, 2015 at 2:18 PM, R. Ransbottom <..hidden..> wrote:

> > Any references or tips on segregation of local changes appreciated.

> Ok. What type of changes are we talking about here? Are you talking about
> adding columns to tables?
>
> If you're talking about adding tables, then it's probably best to have a
> separate schema and add the tables you need to that; that way, when
> LedgerSMB is upgraded, your added tables remain untouched.

By priority, high to low:

1) Adding fields to tables and forms.

Ok. This can only be done in separate tables if you create a 1-1 relationship between the primary table and the annotation table. Usually, adding fields to the schema directly is easier; however, the note is true: on version upgrades (1.3->1.4->1.5) the added columns don't get migrated. However, they don't get destroyed either. Instead the data from the old version gets saved in a separate schema.

2) Possibly adding tables linked to tables. Legacy fields like 'url'
have been repurposed by users. I prefer to just dump such stuff into
the comment text. A dispute I expect to win. Either way, the mess is
dealt with by hand.

Ok. This is easily done in a separate schema, which I think is advisable here.

3) Protecting against browser lockups. A default search on parts,
yields over 27000 items. Postgres does this in a flash, goods.pl
about 4 minutes,

Yea. The slowness probably comes from Template Toolkit generating the entire output. TT isn't known for its speed and faster "replacements" exist, however, we're not aware of more than 1 or 2 other installs which suffer from the same problem.

and the browser page goes unresponsive before scrolling through that data.

Ok. What solution are you adding? If it's pagination, maybe we can work together to add that to the base product?

4) Changing the layout of some screen forms--parts, and the purchasing and sales
chain of forms.

If I want to maintain changed code, I usually branch it off of the original code base and maintain my own branch for however long I need it. Using Git or Hg (Mercurial) should allow you to merge all the changes from the main development line into your own branch quite nicely. I'm doing that myself and I haven't had any problems worth mentioning.

5) Minor logic changes in sales forms--extra fields that are derived from user
input, some of which are saved. Extending the ability of 'terms' logic.

Ok. This is a combination of (4) and (2), I guess.

N) Reworking or extension of the headings/accounts logic, so more than one
kind of balance sheet and income statement can be run. I'd think LSMB
could incorporate this.

Right. I've been working on this. The first step was to make the headings/accounts logic work *at all* in 1.4. And even though I'm not satisfied with the reporting side of it, at least it works for the configuration side.

The primary issue would be that LSMB requires
the usual-at-least-to-me sequence of GL accounts being Assets, Liabilities,
Equity, Income/Revenue, to Expenses/Losses.

You mean you'd want to use hierarchies to deviate from that order?

Incidentally, setting up or doing much modification of a CoA through the
web interface is brutal.

Yes, that's mostly meant to change a prior CoA. I've been uploading my CoAs for all companies I've set up so far (and tweaked them using the web interface from there.)

You were also asking about recent database documentation. I've just regenerated the database schema docs for the 1.4 branch here:

https://github.com/ehuelsmann/LedgerSMB/tree/1.4-schema-update/doc/database

Bye,

Erik.

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

Robust and Flexible. No vendor lock-in.