The long term goal of the OFBiz project is to build a complete, features set rich, universal and configurable "enterprise automation software" (ERP, CRM, CMMS, MRP etc.).
OFBiz is one of the few applications of this type developed by a community, rather than one corporation.
Even if the final long term goal is clear and well-defined ("building a universal enterprise automation software"), the short and medium term tasks to accomplish it are not.
The following is a proposal for the definition of a list of short and medium term tasks list: your input, suggestions and help is welcome. Please add your comment at the bottom of the page.
Content
Add at least a versionning system to the content management
The jackrabbit branch has been created https://svn.apache.org/repos/asf/ofbiz/branches/jackrabbit20120501
have a SFA/CRM which is comparable, in terms of features, to the more popular open source SFA/CRM applications
Improve and enhance the Project Manager Component
See the project specific page here
People interested:
People willing to help: Nicolas Malin
Change the Entity Engine to be user aware for security, logging
This would be a change to require that a userLogin be passed to all Entity Engine calls. The Entity Engine could then check permissions to see if the user can modify or view that entity, or that record. The Entity Engine could also auto-populate fields like created by and updated by.
There are big downsides to this in that it is a real pain to ALWAYS have to know which user is doing stuff, and lots of our services don't know who the user is or use the "system" user to get around security constraints. The same thing would have to happen if we did this for the EE. This would also require major API refactoring, which we would probably want to precede with a big reduction in API size, as has been started but isn't yet finished.
Maybe the API refactoring wouldn't be necessary if we created a user-aware decorator for the GenericDelegator.
Especially regarding lifecycle mgt of recipes (BoM and production schema) and on in-situ adding materials, production resources and outputs of end and by-products (like we had the discussion on dev ML about in September 2013).
http://markmail.org/message/i7fnxid55cq5uiiz
http://markmail.org/thread/6hvrvzkdz2huennv
(neglected for a long time)
Note: IMO (jleroux) the HATEOAS point must be totally respected
(this section related with the "UI (User Interface) enhancements" section, to be clarified)
It would be genuinely interesting if we could write a client side form widget interpreter that would delegate generation of the interface to the client side and then supply the "action" interface via AJAX. It may be interesting to approach this as a "bridge" where we begin to layer dynamic AJAX functionality more aggressively onto the existing widgets.
Note: Adrian did something related for a client, where he replaced the current HTML macro by Sensha code
(this section needs to be checked and possibly split into more accurate sections)
Links in screenlets.
To have in the results list form of every FindScreen (optionally) a first column of check boxes that let the user to select several items and than a combo box above the list that let the user to select a command to execute on them.
Following Bruno's suggestion about Compiere UI. We could put a link to https://localhost:8443/partymgr/control/createnew everywhere we have a party lookup, using the party label at left of the field. Actually we could generalize everywhere we have a lookup for something.
It's easy to click on the Party tab and then on "Create New". But after reading BJ's reading suggestion, it's also an easy way to teach newbies how to do it. Easy for us to introduce, and easy for newbies to use, maybe with a tooltip "click on party to create". This would fill the Condition #2 of the BJ's article above.
Of course being able to show the screen where the choice of the type of party to create is done, and then the screen where data are entered in an Ajax filled CSS hidden/shown window could be our next target. This would allow to not leave the page the user is on and would create a less disturbing environment.
For a first effort, it was suggested that tools tips that direct the user to the necessary steps would be sufficient. Like "create new ($whatever) by clicking on ($whatever1) tab and click on ($whatever2) link" could make the tooltip a template and ($whaterver1-2) is the only things that is a variable. Of course then you can enhance the tool tip to handle links. Then you could just modify the I8N files without touching code "Click here to ($whatever)"
The tooltips labels could be in there own file for an entity. A class that would bes similar to the one that maintains the DB tables can be hooked into Create of the file to add the tooltips. This could be set to defaults based on the Field type.
Now we have the ability to put parms into the label in the I8N files, so the tooltips would have the same ability. Like "Click here to ($whatever)" would turn into "Click here to see the productlist" as a tool tip. You would just have the fieldname like in the labels file.
Barring having a seperate file, then having the tooltip_$fieldname like tooltip_$Phonenumber would work.
Several uses cases has workflow that user has to follow. A common example for this in ofbiz is shopping experience. It makes sense to add conversation scope or data members in form widget. It will facilitate development of workflow intensive UI.