No one is lowering the bar. The problem is, you still don't understand how an open source community works.

Let me give you an example:

I helped design the custom XML file format OFBiz uses for UI labels (https://issues.apache.org/jira/browse/OFBIZ-1442). There were people in the community who disagreed with the design, but it was committed anyway.

For the next few months, there were a lot of commits to fix bugs that cropped up after the initial commit. Scott and David helped with the bug fixes and improvements.

Eventually, the new feature was working well - but there were still hundreds of properties files that needed to be converted to the new format. That was done over a period of several years by many different people.

Today, it would be hard to imagine OFBiz without the custom XML format.

This is how open source works. We start with a bit of code and then everyone contributes their part to improve it. If we did things your way - code is not committed until it is perfectly complete and bug free - then the project would come to a screeching halt.

You have a choice:

1. Continue trying to force everyone in the community to accept your viewpoint of how the community should work.

2. Accept how the community works and participate in it.

Adrian Crum
Sandglass Software
www.sandglass-software.com

On 6/19/2014 11:54 PM, Pierre Smits wrote:
Adrian,

Thank you for your opinion. And for lowering the bar.

This code dump isn't a workable solution for - as a caption on the OFBiz
website states - 'the best e-commerce and Enterprise Resource Planning
(ERP) software available.

Instead it is a waste of time and an insult to everybody who designs and
develops good, thought-through business solutions for OFBiz, and you should
be offended to.

Did Hans hand over his committers userId and password to one of his junior
developers or the intern of the week? Because this is definitely not even
close to the same level of quality and coherence as the project mgt or
scrum solution. And if he didn't, it can surely not be regarded as 'going
the extra mile' visavis completeness or working with the community.



Pierre Smits

*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com


On Thu, Jun 19, 2014 at 4:19 PM, Adrian Crum <
[email protected]> wrote:

I don't see why it needs to be reverted. If it needs to be built out more,
then devs can supply patches for that.

There have been many times in the past where some basic functionality is
introduced to the project, and then it is up to the rest of the community
to finish building it out.

Adrian Crum
Sandglass Software
www.sandglass-software.com


On 6/19/2014 5:26 AM, Pierre Smits wrote:

Hi All,

I finally had some time to review the functionality and code submitted
under:

     - http://svn.apache.org/r1573884
     - http://svn.apache.org/r1574400


The functionality is available in the demo environment on
https://ofbiz-vm.apache.org:8443/accounting

The code is related to OFBIZ-3169
<https://issues.apache.org/jira/browse/OFBIZ-3169>, but apparently the

committer (Hans Bakker) didn't feel the need to follow due process by
adding the improvement as a patch for review by other community members
before dumping it into trunk.
Though it may seem that missing budget functionality can be regarded as a
bug, it should be considered an improvement and therefore it should follow
the Review-then-Commit principle in stead of Commit-then-Review.

Functionality overview:
Basically the functionality allows users of the the accounting component
to:

     - search and find existing budget request
     - create a new budget request
     - enhance the budget request with
        - budget items
        - budget request roles
        - budget request reviews
     - change the status of the budget request


Findings:
First of all, documentation describing the functionality and how to use it
is not available. This is a mayor omission. Assessment of usability by end
users is hindered by this lacking.

Secondly, the functionality as presented works. No errors occurred when
clicking on the various buttons and executing basic process steps, like:

     - adding removing budget items
     - adding and removing a review
     - adding and removing a role
     - Changing the status of the budget request


But, can we say that this functionality is complete and lifts OFBiz in
general and the accounting module in particular a step higher on the
ladder
towards best of breed in the category 'Open Source ERP Projects c.q.
Solutions'?

It definitely does not. The functionality appears, though included in the
accounting module, to be an island. Budgets in general (and at least), are
related to organisations (in OFBiz the internal organisations), P&L
centers, gl accounts, and persons. This is lacking in the functionality.
No
internal organisation can be assigned, nor a P&L center or at the lowest a
gl account. Budgets without such associations are meaningless.

No permissions where incorporated in menu-items to ensure that
functionalities can only be executed by appropriate users. No roles were
predefined, which is customarily applicable regarding this kind of
functionality. Not every users having access should be able to create
budget request, or perform subsequent actions.

Lacking this, the user can (must?) select any partyId and roleId to
associate with the budget request. Even parties not working with (or
allowed to work with) OFBiz in general and the accounting module in
particular can be selected.
But also due to the lacking possibility to set the internal organisation,
no default currency is set. Thus, making the amounts ambiguous to
interpret.

Furthermore it provides only a basic workflow process consisting of
(approve, reject and review). Associating a party to a budget request
doesn't warrant that others can not manipulate the content/data associated
with the request. When I approved a budget request, I had the button to
reject available. This shouldn't be possible. And at one occasion I could
click the 'reject' button multipe time to get to the final state.
While status changes are registered, it should also show who invoked the
status change.

Due to the fact that arbitrarily any party can be associated to a budget
request without any restrictions, the workflow is rendered meaningless.

Conclusion(s):
This solutions hasn't been thought through properly and does no good for
the quality of OFBiz (both the project and the product) in general and for
the accounting module in particular. Prior to dumping the code into trunk
it should have been posted for review by the community, so this could have
been avoided.

If any other contributor to this project made such a set of
functionalities
available as a patch to an OFBiz issue in JIRA, it would sit there for a
great length of time before it would have been committed.

I advice to remove it from trunk.

Regards,

Pierre Smits

*ORRTIZ.COM <http://www.orrtiz.com>*

Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com



Reply via email to