Share an Issue/Epic To Multiple Projects or Groups
Problem To Solve
We have a defined knowledge architecture, but the rigid inheritance model behind it does not allow customers the flexibility they need to flow planning objects horizontally across the hierarchy. For example:
- There is no way to display an issue from Group A on Group B's Issue Board.
There is no way to allow an issue from Group A to be associated with an Epic in Group B.- There is no way for an issue in a "shared" repo to be assignable to an Iteration within a team's Group outside of the Group hierarchy the repo is within.
- Group B does not want all of Group A's issues on their Board either, so the solution must not rely on global Group Sharing as not everyone in the origin project should have access to the target group/project.
Related Issues
There are a plethora of valid use cases that all share a common root cause.
Related issues with similar root causes:
- cross-group milestones
- Permission label management
- Protected labels
- Allow labels to be protected
- Confidential labels
- Confidential labels (2)
-
Personal issue Boards as all issues someone has access to could be organized, labeled, etc. within a Board in their own
Namespace.User
. - Ability to invite users to confidential issues
- Can't invite non-member into confidential discussion
- Make it easier to add people to a confidential issue
- Default User Scoped Workflow Labels
Root cause(s)
- Namespace membership does not provide the necessary level of granular access controls for managing and viewing resources. (Related: fine grained permissions)
- There is no standard model for sharing resources among namespaces either by inheritance or direct sharing.
- "Group Sharing" is access only and an insufficient mechanism for defining how resources should be shared among Namespaces.
Meta-data Ownership
Show attribute table
Attribute | Owner | One-To-Many |
---|---|---|
Title | Work Item | No |
Description | Work Item | No |
Comments, Threads | Work Item | No |
Assignees | Namespace | Yes |
Epic | Namespace | Yes |
Milestone | Namespace | Yes |
Iteration | Namespace | Yes |
Time Tracking | Work Item | No |
Contacts | Namespace | Yes |
CVE | Work Item | No |
Due Date | Work Item | No |
Labels | Namespace | Yes |
Weight | Work Item | No |
Designs | Work Item | No |
Relationships | Work Item | Yes |
Health Status | Work Item | No |
Confidentiality | Work Item | No |
Lock Issue | Work Item | No |
Participants | Work Item | No |
Notifications | User | No |
Reference | Namespace | No |
Issue Email | Work Item | No |
To do | User | No |
Proposal
Happy Path
graph LR
A["Namespace A"] --> Issue
B["Namespace B"]
B -->|owns|LB["Label X"]
B -->|owns|MB["Milestone Y"]
B -->|owns|BB["Board"]
B -->|owns|BE["Epic"]
Issue -->|shared to|B
LB .-> Issue
MB .-> Issue
Issue .->|visible In|BB
A -->|owns|MA["Milestone F"]
MA .-> Issue
Issue .-> BE
Minimal
- A work item can be shared with/to any
Namespace.Project
. - Any
Namespace.Project
that a work item is shared with can associate meta-data owned by the respective Namespace to the work item. - The meta-data is only visible to viewers who have the appropriate access/permissions to the Namespace from which the meta-data originates. This is inclusive of system notes that include meta-data for which a user does not have access.
- Any
Namespace.Project
can be removed from a work item if the user has the appropriate permissions to do so. Meta-data from the removed project is also removed from the work item when the share is revoked. - A work item must always be shared with at least one
Project.Namespace
. - When filtering or viewing via a list or board, only meta-data owned by the work item or owned by (and eventually shared with) the current
Namespace
are visible. - A work item may be shared with a maximum of
Alternative option:
- An epic can be shared with/to any
Namespace.Group
. - Any
Namespace.Group
that an epic is shared with can associate meta-data owned by the respective Namespace to the epic. ..... - Migrate the "sharing" functionality to work items as part of the workstream of migrating epics to work items.
Viable
- A work item can be associated with multiple values of the same type of meta-data owned by a Namespace. For example, a work item may be associated with multiple milestones from one or more Namespaces. Supported attributes are noted in the table above.
- Once issues are available at the Group level, a work item can be shared with/to with a
Namespace.Group
.
Complete
- A work item can be shared with/to any
Namespace.User
includingNamespace.User
that is not a direct or inherited member of theNamespace.Project
orNamespace.Group
. - All of the same logic for associating meta-data from
Namespace.Project
andNamespace.Group
applies toNamespace.User
. - If
Namespace.User
is not a member of a Namespace to which the work item is shared, open the work item in a modal/route/view outside of the respective Namespaces. - Remove
Participants
and instead use the unified "share" experience to denote participants.
Lovable
- Introduce more granular controls for setting default share permissions for work items, cascading work items down, and rolling work items up.
- Integrate the
Confidentiality
controls into the "share" experience. - Integrate the
Notifications
controls into the "share" experience. - Integrate the
Reference
andIssue Email
meta-data into the "share" experience. - Integrate the
Move Issue
controls into the "share" experience. - Work Items can be "shared" across top-level Workspaces.
- Replicate the same "sharing" model introduced in work items to labels, milestones, iterations, and other resources across GitLab that would benefit from the same standardized model for inheritance and cross-namespace sharing.
Old proposals:
## Proposal A
- Allow an Issue in Group A to be assigned to both Group A (where it was created) and Group B at the same time.
- The issue is visible in both Group A and Group B.
- The issue can be assigned to an epic in Group A or Group B.
- The issue cannot be removed from the Project that it was created within.
- If an issue is moved, it retains the relationships except for the project the issue was created within.
- The issue can be assigned to an Iteration in Group A or Group B.
- The issue can be assigned to a Milestone in Group A or Group B.
- When an issue is created within a project, it is automatically assigned to the parent group.
- Once customizable statuses ( &5099) are available, each Group can define an independent status for the issue.
- Users can only add meta-data from the groups they have permission to.
- If users do not have access to meta data from a group the issue is associated to, show the meta data in plain text with a tooltip explaining that the user does not have access to the related object.
- assign issue to epic in namespace outside of the direct hierarchy
Examples
Relationship Diagram:
graph TD
Group --> Subgroup_A --> Subgroup_A_Issue
Group --> Subgroup_B --> Subgroup_C --> Milestone
Subgroup_C --> Subgroup_C_Issue --> Milestone
Subgroup_A_Issue -->|Link to Subgroup_C Milestone|Milestone
Team_A --> Subgroup_A
Team_B --> Group
Proposal B
- Issues are owned the
Namespace
in which they are created. -
Participants
is replaced with aShare
button - Default sharing settings that resembles with our current inheritance model
- An issue can be shared with an individual outside of the current hierarchy
- An issue can be shared with a namespace outside of the current hierarchy
- Resources from shared
Namespace.User
can be associated to Issues. - Resources from shared
Namespace.Group
orNamespace.Project
can be associated to Issues. - If user does not have permission to a resource from a
Namespace
, it is not shown on the issue detail view. - Search/filtering within a
namesapce
can be done only on Resources that are owned by thatNamespace
(or inherited via the hierarchy which is how it currently behaves) -
Restricted
is the same thing as making the issue confidential to theNamespace
that owns it. -
Anyone with link
is effectively making the issue viewable to anyone with a link to the issue even if they are not a member of theNamespace
that owns it.
Permissions
-
Reporter+
or higher can share work items.
Tier
- GitLab Premium for the base work item sharing
- DRIs for meta-data specify the appropriate tier for multi-parenting of each respective resource.
Edited by Gabe Weaver