On 2/28/2012 11:13 AM, Jacopo Cappellato wrote:
On Feb 28, 2012, at 11:49 AM, Adrian Crum wrote:
An example is your description of the CATALOGADMIN_LTD security group. The
permission check is based on a party role, not a user role. Party roles and
user roles are not the same thing.
Yes, that is an example of a party role that is important to determine if the
user is granted to perform an operation (together with the ROLE permission).
But I was confused about the meaning of "user role" as there is not a direct
relationship with OFBiz artifacts: the ingredients of the security framework in OFBiz are:
* SecurityGroups: this is probably the closest concept to a "user role"
* SecurityPermissions
* *Role entities, i.e. party roles (FacilityRole, OrderRole etc...) but also other
structures (like PartyRelationship etc...) can play a... "role" in this :-)
The lack of a direct relationship is the reason why I came up with my
own design. A user logs into (or is assigned to) an organization context
(an internal organization Party), and data access is controlled by
relating data to that party. That approach permits a user's role to
remain separate from party roles, plus it allows the user to log into
different organization contexts.
I suggested that approach years ago, but it never caught on.
Anyway, I understand the pattern you described and I agree the
differences between ROLE and ENTITY permissions need to be handled in a
consistent way.
-Adrian
