Things are never as clear cut as they first appear and simple bugs are often fixed pretty quickly.
In this case however, a committer cannot just grab Abdullah's patch and dump it in without first taking time to understand the problem and the proposed fix. There are a number of issues to consider especially since we are talking about expanding the level of authorization that a customer has. The patch could indeed make this error go away but the committer has to be quite sure that the customer can't then go in and somehow make any old order adjustment that they like (100% discount anyone?). There is a risk here of actually creating a larger and less visible problem if the solution is not thoroughly verified. If a problem is time consuming to solve and doesn't receive much community attention then the committers are far less likely to jump in and deal with it unless it affects them directly. Our time is limited and we do the best we can. Regards Scott On 15/07/2010, at 12:43 PM, Mike Z wrote: > My apologies to all. I didn't mean to offend. I think ofbiz is a > fantastic project, and I'm very grateful for the community > involvement, developers, and contributors. I'll try to behave better. > > On Wed, Jul 14, 2010 at 5:16 PM, David E Jones <[email protected]> wrote: >> >> Please understand that when you are speaking of the OFBiz "community" (or >> any Apache community) there is no "us" and "them". OFBiz is a >> community-driven project, meaning everyone involved in the community is a >> volunteer contributor, even those with commits privileges. None of the >> committers have any responsibility to you, so you'll need to try a different >> approach than blame, complaints, and pushing false divisions. I don't know >> how you normally deal with people you want something from, but there are >> better approaches to get people to do things. >> >> If verbal abuse and attacks don't work, maybe you should step it up a small >> notch and try force, or at least threat of force? BTW, this is best done >> through lawyers and government as they prefer to be the only ones to do such >> things. If you're successful in a lawsuit perhaps you can get the police to >> come and arrest any community member with commit privileges who won't commit >> the patches you want. Oh wait, maybe that won't work either... that would >> just cause everyone in any jurisdiction you manage to manipulate to run away >> from the project and not be a committer any more, preferably before any >> personal legal action or arrest comes their way. Hmmmm. Maybe that won't >> work so well. >> >> There must be some sort of better way... >> >> -David >> >> >> On Jul 14, 2010, at 6:01 PM, Mike Z wrote: >> >>> The community (Abdullah Shaikh) took the time, researched, identified, >>> coded, and submitted a patch. I don't know what more could have been >>> asked of the community. I'm a new guy here true, but I'd like to know >>> that if I took the time to submit a fix to ofbiz, for the benefit of >>> the community, that it would be taken seriously, especially patches. >>> >>> Since the feature doesn't even work, and creates a big ugly red >>> message to the user, I would also guess that most implementations >>> would choose not to enable this feature. >>> >>> I guess I'll need to create my own local svn repository and patch it myself. >>> >>> On Wed, Jul 14, 2010 at 12:50 PM, Scott Gray <[email protected]> >>> wrote: >>>> Each release is only as good as the community makes it. Community is the >>>> key word here, nobody gets paid to make sure Mike Z is downloading a bug >>>> free release. >>>> >>>> My guess is that most implementations have chosen not to allow customer's >>>> to cancel their orders and hence the bug doesn't concern them. If it >>>> concerns you then download the patch, test it, report the results and >>>> eventually a committer will find some spare time to look at it and >>>> possibly commit it. >>>> >>>> What else? Possibly plenty else. You can view the reported unresolved >>>> bugs by release in jira and you'll also need to be open to the possibility >>>> that there are other unreported bugs. >>>> >>>> It is up to users of the release like yourself to test the features that >>>> you need working and if they aren't then report them. Like I said, the >>>> release is only as good as the community makes it. >>>> >>>> Regards >>>> Scott >>>> >>>> HotWax Media >>>> http://www.hotwaxmedia.com >>>> >>>> On 15/07/2010, at 4:55 AM, Mike Z wrote: >>>> >>>>> I'm testing my new store, when I decide to login as a user and cancel >>>>> an order (which is suppose to work). The user sees this: >>>>> >>>>> The Following Errors Occurred: >>>>> Error calling event: org.ofbiz.webapp.event.EventHandlerException: >>>>> Service invocation error (Could not commit transaction for service >>>>> [cancelOrderItem] call: Roll back error, could not commit transaction, >>>>> was rolled back instead because of: Error in simple-method [Auto >>>>> create OrderAdjustments >>>>> [file:/opt/ofbiz-9.04/applications/order/script/org/ofbiz/order/order/OrderServices.xml#recreateOrderAdjustments]]: >>>>> ; [Security Error To Run Auto Create Order Adjustments]) >>>>> >>>>> Odd. Looking further, I discover that a bug was submitted back in >>>>> OCT09, priority MAJOR, with a patch, and verified: >>>>> >>>>> https://issues.apache.org/jira/browse/OFBIZ-3075 >>>>> >>>>> Why wasn't it fixed in 9.04 SVN? I'm sorry, but as a brand new user, >>>>> the reason I chose 9.04 is because it is suppose to be the golden >>>>> build, patched as required, rock solid. All new users are directed to >>>>> 9.04. >>>>> >>>>> The bug actually exposes my INTERNAL paths! >>>>> >>>>> So I have to ask. What else???? >>>> >>>> >> >>
smime.p7s
Description: S/MIME cryptographic signature
