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.
Acceptance
-
Iteration plan for moving Issue
toNamespace
. -
Improved performance for querying issues owned by Namespace
and inclusive of issues owned by children Namespaces. (set benchmark and goals before implementation) -
Inclusive of WIP for Work Items. (&6033)
Maturity roadmap
Available:
- A
Namespace.Group
andNamespace.User
can create anIssue
. - 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 inNamespace
. - A
Namespace.*
issue can still be closed/reference by an MR in a childNamespace.Project
Viable:
- Option to create a new
Issue
fromGroup
+
button in global header. See [1] (frontend) - Ability to select child
Namespace.Project
when creating a merge request from aNamespace.Group
issue. See [2]. (frontend required) -
Namespace.Group
analytics include issues fromself
in addition tochildren
issues.- VSA
- Insights
- Issue analytics
-
Namespace.Group
statistics include issues fromself
. Verify otherissue
counters return issues fromself
and all childrenNamespace.*
See [3]
[1]:
[2]:
[3]:
Complete
- The
Namespace.*
is the default target for creating a newIssue
. See [1] (frontend) - Ability to disable
Issues
inGroup > Settings
. There probably should be a separate epic tracking parity of Settings and Navigation inNamespace.*
(UX / frontend required)
[1]:
Instead of requiring a selection first, default the pickers to the current Namespace
:
Loveable
- Ability to filter views by
Namespace
and/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.Project
orNamespace.Group
when creating new issues or MRs from an issue so a user doesn't have to paginate through a list of hundreds ofNamespaces
to 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
Issue
toEpic
will cease to exist in the future as you will be able to just switch the type ofWork Item
- 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).
FAQ
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
Namespaces
. - A child
Namespaces
can 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.
Edited by Nick Post