Surface work item type in popovers, work item detail view, and issue lists

Problem

As we are working on moving from a world of issues to a world of work items with types, type is an increasingly important piece of context that should be elevated from a presentation standpoint.

Proposal

• Show work item type in popovers
• Show work item type more prominently in the work item detail and legacy issue views.
• Show work item type in the issue list

UX

Proposals in design manager; historical discussion: &5418 (closed)

Type indicator background and design

There’s a bit of history with this tracing back to the introduction of “issue types” (e.g. incidents), most discussion on this can be found here: &5418 (closed). The overall goal was, and still is, to make visible which type an item is without having to open the item or apply a filter from the issues list. From a UI perspective the goal was to create a reusable pattern, the result being a paired icon/ID on lists, boards, and popovers. This could possibly be used on the detail page as well, but as the ID is in the breadcrumb (a reused component) and as the type can be changed from this view (but none of the others) a slightly different treatment was used to give this a little more prominence.

Status

In various places in the application we’re using an open/closed issues icon. This is persisted as a way to maintain consistency with MRs and Epics, and these exist under “Issues”. Epic is not currently an issue type; it exists only in groups and while you can promote issues to epics this behavior closes one and creates another, distinct from changing an issue to an incident which just changes attributes. In the future it will be a work item type, at which point it will be standardized with other issue/work item types (&6033).

With the goal of introducing Status (beyond Open/Closed, e.g. In Progress, Canceled) as an attribute to all work item types (#368290 (closed)), type should be separated from status to allow greater flexibility for both fields. As part of that effort we will identify a reusable pattern to be applied to denote status in every context (lists, boards, detail, popovers, relationships, expanded GFM links, etc). In the meantime we’re updating linked items to use the newer issue icon to fix an outstanding inconsistency (#369924 (closed)) and align with other current status indicators.

Issue type Issue

One result is there is both an “issues” icon, and an “issue-type-issue” icon; from a basic semantics standpoint this isn’t ideal but this has been present for a while with all issue types being present in the issues list (i.e. you could filter your issues by type “incidents”, and see no “issues”). This is part of the reason for the eventual label change to “Work items” however that will be a big, sweeping change, and not one we were trying to make just yet. You’ll hear “work items” from the Plan team within GitLab, but “work items” is not highly visible in the UI yet — users will continue seeing these as types of issues.

Color

One of the findings in &5418 (closed) was that color can be effective to help differentiate; I’d still like to explore this but wanted to start with gray as a slightly smaller change, especially while labels add so much color already to lists/boards. While the original suggestion was to just use the surrounding text color for the icon, we can use $gray-500 for all placements to lighten this up a bit; at the moment only detail pages would be affected (tracked #370806 (closed))

Icon tooltip

Adding a tooltip to locations where a label isn’t used will help clarify the icon intent (#370805 (closed))

Acceptance

• Work item type shows with each work item (or issue) in the issue list
• Work item type shows in popovers when hovered over a referenced work item (or issue). If type is a task, id in reference should be the id instead of the iid.
• Work item type shows more prominently in the work item (or legacy issue) view
• Work item type shows more prominently in the Linked Items widget (#366207 (comment 1016536322))
• Add work item type icon to reference. If the work item is a work-item, use the id instead of iid.