Investigation - Migrating Issues to Namespaces
We need to investigate the work needed to transition issues feature to be tied to a namespace instead of a project. This means that issues should be available at the project and group level with minimal customization. The end result of the investigation will be a list of considerations, a backlog of issues and a high-level estimate of effort.
Iteration plan for moving
Improved performance for querying issues owned by
Namespaceand inclusive of issues owned by children Namespaces. (set benchmark and goals before implementation)
Inclusive of WIP for Work Items. (&6033)
Namespace.Usercan create an
- Issue is visible in
Namespace.*List and Board.
- Issue detail routes are mapped to the
Namespace.*where the issue was created.
- Issues from child
Namespace.*are also visible in
Namespace.*issue can still be closed/reference by an MR in a child
- Option to create a new
+button in global header. See  (frontend)
- Ability to select child
Namespace.Projectwhen creating a merge request from a
Namespace.Groupissue. See . (frontend required)
Namespace.Groupanalytics include issues from
selfin addition to
- Issue analytics
Namespace.Groupstatistics include issues from
self. Verify other
issuecounters return issues from
selfand all children
Namespace.*is the default target for creating a new
Issue. See  (frontend)
- Ability to disable
Group > Settings. There probably should be a separate epic tracking parity of Settings and Navigation in
Namespace.*(UX / frontend required)
Instead of requiring a selection first, default the pickers to the current
- Ability to filter views by
Namespaceand/or the ability to show all issues from child Namespaces or only issues from current Namespace. (UX / frontend input required)
- Make it more efficient to select the most probable
Namespace.Groupwhen creating new issues or MRs from an issue so a user doesn't have to paginate through a list of hundreds of
Namespacesto find the ones they use most frequently. (UX / frontend input required)
Considerations based on the future ideal state
- Epics and Requirements will be migrated to a
Work Item(Discussion: #332566)
- Promoting an
Epicwill cease to exist in the future as you will be able to just switch the type of
- A work item can have multiple parent work items.
- A work item can belong to multiple
Namespaces(#296668) or an equivalent technically feasible solution that allows for work items to roll up to parent work items in adjacent Namespaces and be visible within those Namespace views (Boards, List, and so on).
Q. How do issues flow in the hierarchy? Is an issue created at a group level visible in child groups/projects or does it only flow up the hierarchy?
A final decision has not been reached yet, but If we had to make one today, it would work like this:
- Worked items flow up a hierarchy just like Issues and Epics do today. In the future, we will figure out the ideal solution for rolling them horizontally across one or more
- A child
Namespacescan assign issues to parent work items (and in parent groups) that are non-confidential.
- If a work item is marked as
Confidential, it will follow the same permissions rules are Issues and Epics currently follow in terms of visibility.