On Mon, Mar 5, 2012 at 3:48 AM, Erik Huelsmann
<..hidden..> wrote:
Hi all,
For a new development I need to do something which I consider a "common task" in the application: the user needs to enter data linked to an entity credit account. I've been thinking to solve this along the lines of how this works with payments: the user fills out (part of) a customer name and when there are multiple matches, an intermediate screen is presented to select the correct customer.
Yeah.
Because this functionality is essentially already implemented in new code for payments and something similar (in old code) is implemented for invoices, I was seeing a pattern and saw opportunity to factor it out into a common module. Asking Chris how to approach this best, he said he needs something similar to search for parts and services, but that he doesn't like how it's currently implemented for payments.
My concern as to how it is handled for payments is that it is really a one-off, when we should be looking at centralizing and encapsulating this in appropriate modules. it works fine for what it does, but centralizing the logic and refactoring appropriately would mean we'd have a few less maintenance points going forward. I think it provides a reasonable way to see how we need to do it. It mostly needs to be refactored a bit and generalized.
Being able to refactor some of this into a generic controller routine would also be helpful, and I need to work on this for parts for 1.3.13 so we can finally close the gap on the price matrix functionality compared to 1.2.
So, that's when we decided I'd write to this list...
Basically, what I want to do is: create a data entry screen with a customer name and account description on it. When either of these fields is modified, I want the system to search for a matching entity credit account when the user clicks "Update" or "Save". If there are multiple options, I want the system to present the options to the user for selection.
Sounds good.
However, if the data in the data entry screen is modified w.r.t. what's in the database, I want the modified data in the screen to stay in tact. I also want the data in the database to remain unchanged until the user hits Save -- where I don't want the screen to be saved if the eca selection still needs to take place.
Also, it seems silly to implement this everywhere. So, I'd like this to be a common function callable from any module. (I assume the same applies to Vendors, btw.)
Agreed.
With this mail, I want to solicit discussion on the requirements and a design for such functionality. Once we agree on the requirements and a design, I'm available for implementing it.
So, comments? requirements?
Quick thoughts: this is something form-dynatable.html should be good at doing. Also we probably have stored procs that can serve as a basis for building this (the one in the payments module for example, but in my view that should be moved to the company module).
I think we could probably rename/move the stored proc within a stable version (maybe for 1.3.13.
Bye,
Erik.
PS: Ideally, we have only 1 module which could do the same for customers/vendors and parts/services or any other table for that matter.
I am thinking of the following:
Something in LedgerSMB/ScriptLib/ that can provide the controller logic and routines in LedgerSMB::DBObject::Company, and elsewhere to provide the actual search since the requirements may be different for each module.
I have some other design ideas floating in my head but they need to settle a bit... so anyone else have any ideas?
Best Wishes,
Chris Travers