All, I would like to bring in this discussion the framework/applications relation and dependence. With this I mean that, since we are going to release the framework by itself, I guess the party will not included in it. On the other hand the security is implemented in the framework. So I ask, is it possible to have a basic framework with user authentications, permissions and roles to be used in non strictly ERP applications?
Thank you, -Bruno 2008/6/19 Al Byers <[EMAIL PROTECTED]>: > Adrian, > > This is good timing for me as I need to implement a security scheme in > which > a user's ability to perform CRUD operations is dependent on their level > within an organization (ie. someone is a divisional supervisor so they can > only modify records within their division and its departments). Does this > functionality already exist? Something similar was done for content > management. > > If this functionality were to be rolled into LDAP service, then I think the > LDAP would need to handle a person's party group role associations. It sort > of makes sense that if you want to manage a person's authentication outside > of OFBiz that you would want to manage their position/role assignments in > the same context since they are often related. > > Going back to the integrated CRUD permission scheme, I am prepared to write > that if it is agreed that it is the right way to go. I would make the > assumption that permissions are always determined by where a person exists > in an organizational structure (but certain Security permissions would > override this contextual permission granting) - which is architected by > using the PartyRelationship entity and a person's role within that party > group (div, dept, etc.) I would like to see PartyRelationship used to > associate roles of a person with a party group because it can be time aware > and it can enforce some checks by use of the PartyRelationshipType. > > In general, I am thinking that it would be something like a divisional > supervisor needing to approve Content published by a departmental worker. > The Content record would need to be tied to a department PartyGroup and the > divisional supervisor is able to edit or publish the content by virtue of > their hierarchical position and "ADMIN" role. In other cases, instead of a > Content entity, it may be the ContactMech for an employee or a purchase > order approval. In all these cases, the entity in question needs to be tied > to a PartyGroup structure and the permission to perform the operation would > be determined by the same method once it was. > > In content permission granting there was the concept of "purpose". For > instance, a departmental supervisor may be able approve some content for > publication if its purpose was the weekly newsletter, but not if it were > for > a corporate report. > > -Al >
