[Meta] Doing Party permissions based on organisational hierarchy in Core

Many different organisations will have complex and differing structures with how permissions should work on the contact information depending on how their organisation is structured in real life. Some organisation may have a very flat structure, some will be allowing end-users of their site to manage some data and some will require hierarchies upon hierarchies of middle management.

In the B2B Starterkit it is aimed at helping sales teams essentially work on leads and so each department needs to have its own selection of parties it can handle that other departments will not have access to. This is covered in this issue here: #1790308: B2B starterkit’s Department based permissions. .

However in true party style I think it is important that we try and allow party core to be as generic as possible so not to have to make assumptions with how the organisation is structured. Even amongst the clients we’re working with we’ve found a number of different potential ways to handle this overall permissions problem and so this issue will be here to keep track of all the side issues and discuss the generic problem.

Personally I do not feel this will be in Party core before we get an alpha released.

Related Issues

#1788844: Party B2B Starterkit Management Permissions system - this is being implmented
#1778682: OG Integration (Party owneship)
#1260782: Integrate with Relation to store Party Relationships (e.g Father->Son)
#1788780: Make permissions more intuitive and less complicated
#1790308: B2B starterkit’s Department based permissions. - this will possibly not get implemented

Useful Modules

http://drupal.org/project/workbench (and its “sections”)
http://drupal.org/project/relation - Doesn't work so well with party
http://drupal.org/project/entityreference - Works well with Party
http://drupal.org/project/og - Organic Groups

Different ideas of how this problem could be solved.

Idea 1 - Pure Relationship based approach

We use a relations based concept of ownership and apply permissions to users that “own” a party. We create a relation “X Manages/ is managed by Y” or just use entity reference to make a field “Manages X” on parties. Then we make it so that ownerships that apply to the user of party Y also apply to the user of party X.

This is very simple and easy to do but it means that if a boss leaves the company then the manages relationships will have to be changed on every party.

Idea 2 - Departments based approach

Here we create parties called “Departments”. These can be related to each other in a hierarchy. Staff parties can also be related to the departments and some with the relationship “part of” and some with the relationship “boss”

This is advantageous because the concept of a “department” could exist in real life. It means it will exist in drupal allowing people to do things such as add content into a department. They could have their own home page, calendars, etc.

Idea 3 - Hierachical Roles approach (used by salesforce)

This is completely generic and flexible. There are new things called “Roles” that can all be related to each other and permissions travel through the different relationships. Users can be put into the roles.

I feel that because this is used by other systems there is something in it. It feels like this can essentially be achieved by core Drupal roles anyway but maybe something could be built on top of things to make them more manageable? Me, David and Rob are all uncomfortable with this approach but we can’t figure out why.

Ideas 1-3 - Issues
All these ideas require some concept of “Party ownership” that is more than the normal Drupal concept of ownership (or author). All of these require a fairly complicated view that shows off the hierarchy for any of it to make any sense. All of these approaches start by capturing detailed information about the organisation itself and base permissions off of that. This may make UIs much nicer in some situation, but more complicated in others.

Idea 4 - Organic Groups approach
We’re using this for one of our clients.

As parties are entities they can easily be “groupified”. This allows us to add users who can manage that group. By making a new permission that OG can use only users of that group can manage those permissions. OG already sort of has different roles and great UIs to allow people to do things such as “request membership”.

OG groups do not seem a good approach for storing company hierarchy. How much of OG do we need to rebuild to make this work and it appears OG is moving towards relations anyway.

Idea 5 - Workbench Spaces approach

Technically this is probably not worthwhile. However Workbench have tried to solve the content authoring experience with its concept of “Sections”. It is possible to make all the nodes in a section of the site editable and managed by a particular group of people.

Workbench works with nodes, not entities and so it may have to be significantly hacked. However framing the question this way may be helpful. Aren't different departments managing different parties the same as different publisher managing different nodes in different sections? Is it better to see this is a workflow problem rather than just permissions and hierarchy?