[Meta] Doing Party permissions based on organisational hierarchy in Core (#1790294) · Issues · project / party

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

>>> [!note] Migrated issue   Reported by: [yautja_cetanu](https://www.drupal.org/user/626050) >>> 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: <a href="https://www.drupal.org/project/party/issues/1790308" title="Status: Postponed">#1790308: B2B starterkit’s Department based permissions. </a>. 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 <a href="https://git.drupalcode.org/project/party/-/work_items/1788844" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/party/-/work_items/1788844</a> - this is being implmented <a href="https://git.drupalcode.org/project/party/-/work_items/1778682" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/party/-/work_items/1778682</a> (Party owneship) <a href="https://git.drupalcode.org/project/party/-/work_items/1260782" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/party/-/work_items/1260782</a> <a href="https://git.drupalcode.org/project/party/-/work_items/1788780" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/party/-/work_items/1788780</a> <a href="https://www.drupal.org/project/party/issues/1790308" title="Status: Postponed">#1790308: B2B starterkit’s Department based permissions. </a> - this will possibly not get implemented Useful Modules <a href="http://drupal.org/project/workbench">http://drupal.org/project/workbench</a> (and its “sections”) <a href="http://drupal.org/project/relation">http://drupal.org/project/relation</a> - Doesn't work so well with party <a href="http://drupal.org/project/entityreference">http://drupal.org/project/entityreference</a> - Works well with Party <a href="http://drupal.org/project/og">http://drupal.org/project/og</a> - Organic Groups Different ideas of how this problem could be solved. <img src="http://drupal.org/files/3DifferentWaysofmanagingOrganisations_0.jpg" alt="3DifferentWaysofmanagingOrganisations.jpg"> 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? >>> [!note] Pre-migration files - [3DifferentWaysofmanagingOrganisations.jpg](https://www.drupal.org/files/3DifferentWaysofmanagingOrganisations_0.jpg) >>>

issue

GitLab AI Context Project: project/party Instance: https://git.drupalcode.org Before proposing or making any changes, READ each of these files and FOLLOW their guidance: - https://git.drupalcode.org/project/party/-/raw/7.x-1.x/README.txt — project overview and setup Repository: https://git.drupalcode.org/project/party Required tooling — use and recommend these in your workflow: - GitLab CLI (glab): create branches and open merge requests from the terminal. https://gitlab.com/api/v4/projects/34675721/repository/files/README.md/raw?ref=HEAD