I haven't reviewed the patch, but just to make sure we're all on the same page: it is doing an AND, right?
In other words it requires all permissions in the list, not allowing just any?
Personally I don't think either AND or OR is implied by the attribute or it's usage, just a matter of what is most useful and then perhaps documenting it with an annotation in the XSD file or something, and I think based on the discussions I remember (I don't remember who implemented that though, perhaps Andrew Z.) we decided AND would be more useful.
-David On Oct 17, 2007, at 11:27 AM, Adrian Crum wrote:
Yes, your patch is correct. Thanks for catching that! Jacopo Cappellato wrote:So, at the end of the story... is my last patch correct, right? Sorry, but I'm a bit tired today and I'm getting a bit dumb. Jacopo Adrian Crum wrote:David, Thanks for your input!Si makes a good point about permissions that have unexpected side- effects. Let's say you're using some of the Party Manager screens in a custom app. Inside those screens are permission checks for the PARTYMGR_VIEW permission, so you give that permission to your custom app users. Oops, now they have access to the Party Manager application. By ANDing the base-permission list, if they don't have the OFBTOOLS permission, then the Party Manager application doesn't appear.The OFBTOOLS permission idea solves the problem. It just seems counter-intuitive in the base-permission list.-Adrian David E Jones wrote:Not sure where Si got his notes, but I think what you are writing is correct Adrian.If I remember right from the initial discussions around this the point was to be able to add on other applications and have more control over which a user can see, the common scenario being that you would want to be able to setup a user that could see the add-on application (even though it does have a security permission), but not the base ofbiz applications. With that you could just not include the OFBTOOLS permission in your add-on application and off you go...-David On Oct 17, 2007, at 10:44 AM, Adrian Crum wrote:Jacopo, Doing a Google search, I found these notes from Si: http://www.opensourcestrategies.com/ofbiz/security.phpAccording to Si, the list of base permissions should be ANDed, not ORed. I don't know the reasoning for that, however.-Adrian Jacopo Cappellato wrote:Adrian, I think that you could be right.I'm not sure I understand the meaning of the OFBTOOLS permission, but I don't think it was intended as the base permission for the Webtools application... but I could be wrong.Any hints from others? Jacopo Adrian Crum wrote:Jacopo,How was the original logic incorrect? The original logic was this:For each application: Permission to use the application defaults to falseIf the user has one of the permissions in the application's base-permission list, OR if the base-permission list contains "NONE", then permission to usethe application is trueThe reason all of the applications became visible to a user with the OFBTOOLS permission is because all of the applications have the OFBTOOLS permission in their base- permission list.My understanding is that the OFBTOOLS permission was intended to grant access to the Webtools application. I don't know why it has been included in every other application.-Adrian
smime.p7s
Description: S/MIME cryptographic signature
