Re: Input needed.

["Chris Travers" <..hidden..>]

Hi Del;

The major reason for keeping the development discussion on this list
at the moment at least is to avoid overwhelming basic users with
technical details :-)  Hence I will provide a few quick pointers to
the code here, and we can further discuss the issues here.

Before I begin, I will warn you about the quality of the source code
we have not replaced yet :-).  once you see it and start working with
it, you will see why we are looking at re-engineering the whole thing.
:-)

First, you probably want to take a look at our roadmap and our new
architecture document.  If you can implement the database side in
stored procedures you will find that is helpful (warning:  db design
is to the same standards as the Perl programming).   In short, we are
redesigning the entire customer/vendor structure and interface in
1.3,as well as the base framework.

If you can wait for 1.3, my suggestion is to work with us on this area
for 1.4.  This basically means helping us fully redesign the
project/timecard/job costing system as it will probably be less work
than struggling with that codebase.

On 10/22/07, Del Miller <..hidden..> wrote:
> Hello All,
>
> After some discussions with Chris Travers over on the -users list, I
> have decided to attempt to make some changes to LSMB for my own personal
> usage but would gladly contribute back anything useful (or even
> marginal) that I can come up with.  To that end, I am writing to make
> sure that what I am about to attempt a) will fit with LSMB in the best
> way possible b) is not a duplicated effort c) doesn't step on anyones
> toes ;)

See below.
>
> Here's what I'm thinking and why...
>
> I am a small time consultant and bill on a monthly basis -- LSMB seems
> to have everything I need with one small exception -- I'd like to create
> a non-customer based project (no problem), enter a time card against
> that project and, *on the time card*, have a drop-down list of customers
> from which to select for billing.  I realize that I can enter the time
> cards, generate sales orders, and *then* select the customer at that
> time -- which, functionally, is what I'm after but is a bit less than
> convenient for how I work.

You can also enter timecards, select the customer, and then generate
the sales orders, but that poses the same basic issue you are trying
to avoid.

There are some other usability options also, which I will send on the
other thread.  In short, maybe set up different services, and then
treat projects as customer contracts.
>
> So, being a bit of a Perl programmer (although a bit rusty), I began to
> look at the LSMB code to see how one would shoehorn in a customer
> selection function on the 'add timecard' page.  All I can say it, wow.

Why we are replacing the old code :-)  All I can say is that we welcome help :-)
>
> After a few hours I came to think that my life would be simpler if I
> created a new module, called something like VendorCustomer.pm, that
> would provide all the needed functions  to customer/vendor info...

CT.pm does this.  BTW, CT.pm is going away in 1.3 to be the first
target of our refactoring/re-engineering efforts.

The original author liked short names.   CT stands for Contact.  If
you take a look in svn /trunk, you will see we don't like short names
so much, and our code is remarkably... different... from Dieter's.

> most
> importantly, a 'get_customer' function that could return a drop-down
> selection list and provide a drop-in replacement for the current
> get_customer routine in the PE and RP modules.

For now, my suggestion is that you put your function in a new module
like LedgerSMB::ContactWidgets.pm or the like.

PE and RP are probably the worst of the messes.  If you can avoid it,
I would *hightly* avoid touching those modules any more than we have
to.

RP.pm is going away in 1.4, PE.pm may go away in 1.4 if we get to it,
but is more likely to be between then and 2.0 unless someone wants to
help with it.

>  I would think that it
> could easily be expand it to include add, delete, update, etc. and start
> to be dropped in all around.
>
> Well, anyway, before I go chasing rabbits and put the time in to fix
> things the way *I* want them, I thought it only prudent to address you,
> the developers, so as to avoid any duplicated effort, get your input,
> and see if this would be a useful thing to do, etc.

If this can wait for 1.3, my suggestion is that you work with us to
re-engineer the project/timecard/job costing system.  It need not be
done all at once, but will probably be *less* work than struggling
with the code we inherited.  Notice I said "help" as I would be happy
to provide some effort in this area as well.

>
> Any thoughts/suggestions here?

My only concern is that the inherited codebase is brittle and we are
re-engineering portions of it that your work will depend on.  Since
you are looking at adding customer/vendor functions, I would suggest
looking at what we are doing for 1.3, ask lots of questions, and see
what you can hook into there.

>Apologies if I'm sticking my nose where
> it doesn't belong -- feel free to tell me to go away. :)

Don't worry, we don't work that way,  The purpose for bringing it up
on this list is to ensure that everyone can coordinate what everyone
is doing.  We would also naturally review patches for quality before
applying them, but as 1.3 goes forward, some large areas of the
codebase are getting cleaned up.

Best Wishes,
Chris Travers

>
> Regards
> Del
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Ledger-smb-devel mailing list
> ..hidden..
> https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
>