Issues

The issue view is a table of issues for whatever scope you browsed to, filtered with the same bar and pinned with the same key as merge requests, pipelines and to-dos.

issues
The same table, the same filter bar and the same keys as merge requests.

What you see

ColumnWhat it holds
titleThe issue title, growing to fill the row and truncated at the end
projectWhich repository the issue is in
authorWho opened it
assigneesWho it is assigned to
labelsGitLab's own label colours, with a +n overflow marker
milestoneThe milestone it belongs to
weightThe issue weight
due dateWhen it is due, relative or absolute to match your date format

Columns drop by priority as the terminal narrows, the same way they do in every other table.

Selecting a row opens the preview pane: the description rendered as markdown, then the comment thread.

What you can do

KeyActionKeyAction
ccommenttadd or remove labels
x Xclose, reopena Aassign, unassign
oopen in the browserYcopy the URL

These are the merge-request keys. A key means the same verb in every view, so nothing here is new to learn.

Scope and filters

Tab reaches the issue view. From there the pattern is the one every view shares: browse to a scope, filter it, pin the result.

You wantDo this
Assigned to youf assignee:@me, P
Bugs in one groupb to the group, f label:bug, P
This milestonef milestone:"Sprint 24" state:opened, P

Label, milestone and username values complete from your own instance, so a name in the filter bar cannot be misspelled.

Work items

GitLab models issues, epics, tasks and objectives as work items in its GraphQL API, and is retiring the Epics REST endpoint in favour of it. labdash reads issues through GraphQL, from the same API.

Issues and merge requests

A merge request that closes an issue shows the link in its preview pane, and Enter on that link jumps to the issue's row in the issue view.