Re: Input needed.

[Del Miller <..hidden..>]

Hi Chris,

Thanks, as always, for the response.

I took a look at the road map and the brief architecture outline -- is
there a more in depth document?  I'm assuming there might be and I'm
also assuming that I need to register with the site in order to get
access.  To that end, I registered (about 3 hours ago) and have yet to
receive the confirmation email.  Perhaps the following questions will be
answered once I gain access as a registered user.

I've got bits of time here and there and an itch that desperately needs
to be scratched.  LSMB is the closest thing I've seen to meeting my
needs and it's close enough that I'd like to put in the effort to make
it work.  In short, I'd like to help in any way I can.  Can you provide
me with anything to get me up to speed on the old code, the current
code, what needs done, what is done, how to work with things, etc.

You speak of 1.3 (1.4, 2.0)... is there a time frame for 1.3 (1.4,
2.0)?  Is there a working 'beta' of 1.3 (1.4, 2.0)?  How about
engineering details?

Are there coding standards to read?  If not, that's OK... could you
point me a some well written LSMB code that I can look at to get a feel
for style?

Any sort of database diagram exist?

BTW, thanks for pointing out the CT module as I had not run across that
one yet.  After looking at it, it appears to do everything *but* what
I'm after -- go figure.  I'll set about working on a quick fix for my
immediate needs.

Regards
Del

Chris Travers wrote:
> 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
>>
>>     
>
> -------------------------------------------------------------------------
> 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
>