Re: Change management

["R. Ransbottom" <..hidden..>]

> > 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.

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.

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, and the browser page goes unresponsive before 
scrolling through that data.

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

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.

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.  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.


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

Be well,
Rob



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