On Jan 29, 2008 8:39 AM, Paul Wrightson <
..hidden..> wrote:
Both of the examples cited here are specific-ish customizations for
specific-ish businesses. What I mean be "specific-ish" is that the
functionality does not apply to the majority of businesses, nor just a
single business, but a sub-set of all businesses.
What I believe we need is a framework that allows user-specified
workflow to be triggered under certain circumstances. For example, a new
customer added could trigger an external process that checks the billing
and shipping addresses and also checks an external credit database to
apply the appropriate credit limit to the account and sends a 'welcome'
email. Another example could be to automatically build a vendor PO
whenever inventory falls below the re-order value - triggered by either
a purchase or by a stocktaking function within LS.
That is a good description of the problem. I think the solution involves a two-dimentional modularization of the software:
1) Vertical modularization: Stable SB APIs, Workflow scripts, and templates. This allows people to customize the workflow/UI of the software relatively easily without having to be Perl gurus or have the QA issues that currently affect the legacy codebase. All new or re-engineered code in 1.3 follows the above approach. Also the new menu structure allows one to add new menu items to custom workflows reasonably easily.
2) Horizontal modularization: The current application could be broken down into: core/financial, inventory, and POS modules. CRM, MRP, etc. modules could also be written and possibly bundled. This would allow businesses who don't need some functionality to simply not install it.
Yet another aspect of the solution involves better integration capabilities with other tools.
Workflows of this nature would need specific hooks to start them within
LS itself, but a capability to run "cron-initiated" or "user-initiated"
(from a menu add-on, perhaps), or even "external process initiated" as
in the case of a communication from a self-service portal or POS tool.
The project wiki could keep a collection of user-submitted workflows to
perform specific-ish tasks to extend the functionality of LS without
hindering development by incorporating additional code into the "base"
installation.
Sure. Although I would suggest that we find *some* way to get good hosting for such projects. Whether we recommend Sourceforge, create an installation of Gforge or whatever.......