http://ofbiz.116.s1.nabble.com/Dev-Party-Application-tp167779p167785.html
I don't know if the current security scheme is well documented anywhere, but it's fairly simple so here's a quick summary...
1. application/functionality level security
2. data level security
Category #1 (UserLogin-driven) doesn't know about anything except the UserLogin, the permissions checked for different screens, services, etc, and the SecurityGroup structure that maps between them.
Category #2 (Party-driven) can be combined with #1, usually with special "role limited" permissions that when checked require not just the permission, but some relationship between the Party and whatever records are concerned by the screen, service, or whatever.
It should be possible (in theory, I haven't tested it...) to use the Category #1 security without the party component, but #2 is very dependent on the Party data model and whatever data model relates to it for the required relationships.
This is the general design. What exists OOTB in OFBiz has various examples of both, but no attempt has been made to create a comprehensive or at least "generically complete" set of security settings in either style #1 or #2. Si Chen, et al have put some effort into more granular permissions for style #1, and that is quite helpful.
While much more effort for something like this is needed I'm still not totally convinced of the usefulness. I don't think I've worked with any 2 clients that had the same staff structure and desire for the same set of permissions, though certain ones do come up now and again or could be reduced to a more granular set of permissions that both could use. Whatever the case, this is an area of customization that tends to be pretty complex and there is as much variety in it as there are combinations of relationships of entities in OFBiz. You could write zeroes for a while trying to get a real number for the possible combinations there... ;)
> Security groups are associated with user login (and
> security permissions with security groups), not with
> party. Security groups (has_permission in ftl,
> if-has-permission in screen widget) is (or should be)
> how it's controlled on the application level. I'm not
> saying that much thought has made it into OFBiz in
> this regard thus far. But, in the sales rep example,
> replogin1 would have the security group of say
> WHOLESALE_VIEW, so if you took the ecommerce
> application and added a bit of code to display product
> cost ie..
>
>
> <#if has_permission("WHOLESALE", "_VIEW", session)>
> ${productPrice.averageCost}
> </#if>
>
> salesrep logged in as replogin1 would see it, where
> logged in as replogin2 who does not have that security
> permission (or group that has that permission) would
> not see that line (my syntax may be slightly off in
> the example)
>
> In summary, it's my understanding that the data layer
> is what is checking the associated parties, and the
> application layer is controlling the permissions.
>
> --- Ean Schuessler <
[hidden email]> wrote:
>
>> On Wednesday 26 April 2006 23:12, Chris Howe wrote:
>>> I think the link to party instead of userlogin is
>> to
>>> allow the same party to limit their permissions by
>> how
>>> they're logged in (since one party may have
>> multiple
>>> user names) but still be able to track all the
>> actions
>>> of that person as one person.
>> I don't think it lets you do that. Since the
>> association is by party, the
>> UserLogin will have no influence over the behavior
>> of the application.
>>
>>> Take for example the
>>> scenario that a sales rep has. Having the current
>>> setup allows a sales rep to use one user name and
>> see
>>> his cost for the product when he is in private.
>> Then
>>> have him use a different user name when he is
>> infront
>>> of his client where he certainly doesn't want to
>>> reveal his cost, but rather his client's cost.
>> This
>>> allows the salesrep to learn only one application.
>> In
>>> addition if a username is abandoned, it doesn't
>>> abandon the record of the person.
>> Association by UserLogin would not prevent pricing
>> by Party. Since there is
>> only one Party associated with a given UserLogin you
>> can still do Party based
>> operations from the UserLogin. The only negative
>> side effect is that all the
>> Parties in these types of roles (ie. Vendor, etc.)
>> would have to have
>> UserLogins and that seems a little undesirable.
>>
>> --
>> Ean Schuessler, CTO
>>
[hidden email]
>> 214-720-0700 x 315
>> Brainfood, Inc.
>>
http://www.brainfood.com>>
>> _______________________________________________
>> Dev mailing list
>>
[hidden email]
>>
http://lists.ofbiz.org/mailman/listinfo/dev>>
>
>
> _______________________________________________
> Dev mailing list
>
[hidden email]
>
http://lists.ofbiz.org/mailman/listinfo/dev