### **Problem to solve** Customers have permissions challenges when it comes to managing work items such as Epics, Issues, and Labels along with obtaining wiki access. The problems they are trying to solve include: * Fine grained permissions for who can edit and view work items and related views. * Reporter role has ability to view code. Regulated environments prefer their planning or QA team not to view code. As a result, these teams have to create a separate project which can isolate communication with the dev team. * Using a wiki requires developer access which elevates permissions for planning teams. This forces teams to create a separate project to manage their wiki further isolating communication. ### **Proposal** See [meta issue](https://gitlab.com/gitlab-org/gitlab/-/issues/440701 "Permissions map to a Consistent CRUD Verb Pattern") for CRUD verb patterns * Manage: Includes Write/View/Delete * Write: Includes View * Delete: Includes View <table> <tr> <th>Resource</th> <th>Write</th> <th>View</th> <th>Delete</th> </tr> <tr> <td>Work Items</td> <td> * Create and update work items * Create and update boards </td> <td> * View work items * View boards * View roadmaps * View lists </td> <td> * Delete work items * Delete boards </td> </tr> <tr> <td>Timeboxes (iterations, milestones)</td> <td> * Create and update timeboxes </td> <td> * View timebox reports </td> <td> * Delete timeboxes (iteration cadences, milestones) </td> </tr> <tr> <td>Label Management</td> <td> * Add or update label </td> <td> * View labels list </td> <td> * Delete labels </td> </tr> <tr> <td>Value Stream Analytics</td> <td> * Create and update custom VSA reports </td> <td> * View custom VSA reports </td> <td> * Delete custom VSA reports </td> </tr> <tr> <td>Wiki</td> <td> * Create and update wiki pages </td> <td> * View wiki pages </td> <td> * Delete wiki pages </td> </tr> </table> * Work items include Epics, Issues, Tasks, OKRs. * Work item settings include issue templates, service desk, customizable types (future) customizable statuses (future) Default conditions with custom roles <table> <tr> <th>Default Condition</th> <th>Description</th> </tr> <tr> <td>Confidential</td> <td> * Guest users cannot see confidential issues. * Custom roles can see confidential issues if given access to group or project. </td> </tr> <tr> <td>Authorship</td> <td> * Authors and assignees can modify the title and description. * Authors and assignees can close and reopen issues * Authors can delete work items and comments they authored </td> </tr> <tr> <td>Labels</td> <td> * If you can access work items, you can see labels and assign them to items. </td> </tr> <tr> <td>Relationships</td> <td> * If you have a Guest role in one namespace and a custom role in another namespace, you can link (related, blocking/blocked by, parent/child) work items from one namespace to another. </td> </tr> <tr> <td>Discussions</td> <td> * If you can access work items, you can comment on them. * If you can access work items, you can see internal notes. </td> </tr> </table> ### **Permutation Stress Test** * Project managers can only access project planning resources and are limited to other GitLab resources * Project managers can manage labels at a group or project level without them being deleted ### **User Persona Modeling** ### **Dependencies** * Labels: Creation and managing labels in the work item metadata will be limited based on label permission. * Notifications * TODOs * Comments * Merge requests ### **Evidence** * Variations between epics, issues, and labels. ( https://gitlab.com/gitlab-org/gitlab/-/issues/404872#note_1371419965+) * Restrict issues and epics to specific users. ( https://gitlab.com/gitlab-org/gitlab/-/issues/353129+) * Issue Only Users ( https://gitlab.com/gitlab-org/gitlab/-/issues/21616+) * https://gitlab.com/groups/gitlab-org/-/epics/4035#note_864494024+ * https://gitlab.com/groups/gitlab-org/-/epics/4035#note_868477404 * https://gitlab.com/groups/gitlab-org/-/epics/4035#note_1120378220 * https://gitlab.com/gitlab-org/gitlab/-/issues/391760#note_1857520804 ### **Alignment Review** * \[Plan PM\]: Product Manager * \[Plan Designer\]: Product Designer * \[Authorization Team\]: PM, EM, PD ### Resources * [Figjam diagram of project planning resources](https://www.figma.com/file/nBkQ2Qgk1gHDaiIER0K634/Custom-Role-Permissions%3A-Project-Planning?type=whiteboard&node-id=45-907&t=7h7HRoebEh179IDC-0)