While working on a fix for [issue hierarchy on epic work items](https://gitlab.com/gitlab-org/gitlab/-/issues/500424 "Setting an epic as parent breaks when user is not member of the group for work items") users with just project access, we became aware that the permissions for work items is different to legacy epics and can be simplified. There have been [previous discussions](https://gitlab.com/gitlab-org/gitlab/-/issues/397073 "Update epic relations permissions to match issues") about allowing to link hierarchies between groups/projects by just having a guest role on either one of the groups/projects. We want to simplify the permissions with following goals: 1. Don't break the existing permissions for (legacy) epic \<\> issue hierarchies for work items. 2. Make the permission for hierarchies independent of the type 3. Mae the permission for hierarchies independent for the namespace type (group or project) 4. Make it easier to understand for users ## Proposal After a discussion with @amandarueda and @egrieff the proposal is the following. ### Add work items to the hierarchy To add a work item to the hierarchy, the user needs to have: 1. **Read permissions on both** the parent and the child work item 1. This is necessary for public groups where a work item can be confidential 2. **Guest role** on **at least** the parent **or** child work item's namespace 1. `Guest role` means: they need to be a member of the namespace. Not to confuse with "guest access" which everyone has for public groups. **Example scenarios:** - A non-member can add issues from their own projects to public group epics (current legacy epics behaviour, but not for work items) - A guest on a private project that has read access to the group, can add sub-issues (current legacy epics behaviour, but not for work items) - A non-member can add tasks form their own project to work items of a public project (not possible right now for work items) ### Updating hierarchy To update a work item in the hierarchy (e.g. re-order), a user needs to have: 1. **Read permissions on both** parent and child work item 2. **Guest role** in **both** parent and work item (this is different to create or delete!) ### Remove item from the hierarchy Same as for creation: 1. **Read permissions on both** the parent and the child work item 2. **Guest role** on **at least** the parent **or** child work item's namespace ## Before/After ### Before <table> <tr> <th>Parent Namespace</th> <th>Parent permission</th> <th>Child Namespace</th> <th>Child permission</th> <th>Allowed?</th> </tr> <tr> <td>Group</td> <td>no member</td> <td>Group</td> <td>no member</td> <td>No</td> </tr> <tr> <td>Group</td> <td>no member</td> <td>Group</td> <td>guest access</td> <td>No</td> </tr> <tr> <td>Group</td> <td>guest access</td> <td>Group</td> <td>no member</td> <td>No</td> </tr> <tr> <td> **Group** </td> <td> **guest access** </td> <td> **Group** </td> <td> **guest access** </td> <td> **Yes** </td> </tr> <tr> <td> --- </td> <td> --- </td> <td> --- </td> <td> --- </td> <td> --- </td> </tr> <tr> <td>Group</td> <td>no member</td> <td>Project</td> <td>no member</td> <td>No</td> </tr> <tr> <td>Group</td> <td>can read</td> <td>Project</td> <td>no member</td> <td>No</td> </tr> <tr> <td>Group</td> <td>can read</td> <td>Project</td> <td>can read</td> <td>No</td> </tr> <tr> <td> **Group** </td> <td> **can read** </td> <td> **Project** </td> <td> **guest access** </td> <td> **Yes** </td> </tr> <tr> <td> **Group** </td> <td> **guest access** </td> <td> **Project** </td> <td> **guest access** </td> <td> **Yes** </td> </tr> <tr> <td> --- </td> <td> --- </td> <td> --- </td> <td> --- </td> <td> --- </td> </tr> <tr> <td>Project</td> <td>no member</td> <td>Project</td> <td>no member</td> <td>No</td> </tr> <tr> <td>Project</td> <td>can read</td> <td>Project</td> <td>can read</td> <td>No</td> </tr> <tr> <td>Project</td> <td>guest access</td> <td>Project</td> <td>can read</td> <td>No</td> </tr> <tr> <td> **Project** </td> <td> **guest access** </td> <td> **Project** </td> <td> **guest access** </td> <td> **Yes** </td> </tr> </table> ### After As a reminder: the namespace can be _across the namespace hierarchy_ | Parent Namespace | Parent access | Child Namespace | Child access | Allowed? | |------------------|---------------|-----------------|--------------|----------| | Private Namespace | no member | Private Namespace | no member | No | | Private Namespace | no member | Public Namespace | no member | No | | Public Namespace | no member | Public Namespace | no member | No | | Private Namespace | guest role | Private Namespace | no member | No | | **Private Namespace** | **guest role** | **Private Namespace** | **guest role** | **Yes** | | **Public Namespace** | **no member** | **Private Namespace** | **guest role** | **Yes** | | **Private Namespace** | **guest role** | **Public Namespace** | **no member** | **Yes** | | **Public Namespace** | **no member** | **Public Namespace** | **guest role** | **Yes** | | **Public Namespace** | **guest role** | **Public Namespace** | **no member** | **Yes** | ### Request: Please let us know if the proposed policies for the hierarchy above are okay to implement. **Related links** In addition to the hierarchy, I'd also propose to align the concept for related work item links with the rule: * The **user must** be able to **read both** work items * The user has a **guest role** in either the **source or target** namespace to link a work item