[ http://issues.apache.org/jira/browse/OFBIZ-118?page=comments#action_12449521 ] Adrian Crum commented on OFBIZ-118: -----------------------------------
Si, Thank you for your comments. For some reason I didn't read your comment when you first posted it, so I apologize for the delayed response. The system I developed here uses existing entities plus a custom user settings entity. By using Party Role and Party Relationship, I was able to construct a set of fine-grained controls. Most of the development work was done in the UI - checking the user's organization context, their relationship to the parties being accessed, etc. Anyone else who wants to implement something similar would have to put the same amount of work into the UI - because every deployment will have it's own set of rules. I'm thinking it would be helpful to end users like me to have a generic set of services that will accomodate our type of deployment. In other words, there would be no need to add anything to the existing apps to limit access, but rather have a set of services that can be called to implement custom security checks on an installation-by-installation basis. Those services may be unused by OFBiz out-of-the-box. Does that make sense? If there is any interest in our implementation, I would be happy to discuss it further. I'll try to answer your question with our implementation: An OFBiz user has a role of OFBIZ_USER. The user is linked to a party group that has the role ORGANIZATION_CONTEXT using a PartyRelationship. The relationship type is CONTEXT_MEMBER. The user can log into only those Organizational Contexts that have this relationship to the user. The PartyId of the user's currently selected Organization Context is stored in a user settings entity. As the user interacts with the applications, checks are performed to see if the data being requested is somehow linked to the Organization Context the user logged into. It seems we have traveled parallel paths on this subject. Much of the work you have contributed along these lines is very similar to what I have implemented here. I think this is a feature that could be implemented fairly easily - considering the amount of work you and I have already invested in it. > Roles and Security for Display of data. > --------------------------------------- > > Key: OFBIZ-118 > URL: http://issues.apache.org/jira/browse/OFBIZ-118 > Project: OFBiz (The Open for Business Project) > Issue Type: Improvement > Components: accounting, content, ecommerce, humanres, manufacturing, > marketing, order, party, product, workeffort > Affects Versions: SVN trunk > Reporter: BJ Freeman > > There is a need to be able to block viewing info except that info that may > pertain to that login (partyID) > The is not taking into consideration Admin or Managers levels. > for instance you have employees who should not be able to see each others > profiles, payroll information, and/or time sheets, as a few examples. > another area, if an communication event is set to private, no one but the > party ID associated with the email address should be able to see them. > So this is a discussion about how to best implement this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
