incubator-ofbiz-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adrian Crum (JIRA)" <j...@apache.org>
Subject [jira] Commented: (OFBIZ-118) Roles and Security for Display of data.
Date Mon, 13 Nov 2006 23:29:39 GMT
    [ 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

        

Mime
View raw message