To-dos

The to-do view is currentUser.todos rendered as a table. It scopes, filters and pins like every other view, and one key takes you from a to-do to the row it is about.

todos
The pending count in the switcher comes from the connection, so the size is known before the rows arrive.

What you see

The columns are the action that created the to-do, its target, the project, the group, the author, how long ago it arrived, and the snoozed-until time when it has one. That is enough to triage without opening anything.

GitLab's to-do API covers all of this

The connection filters by action, author, project, group, state and snooze status. GitLab exposes mutations for marking one done, marking all done, snoozing and restoring.

What you can do

KeyActionKeyAction
dmark doneEntergo to the target
Dmark all doneoopen it in the browser
urestore one you just didssnooze

D sits behind a confirm that names the number:

▸ Mark all 14 to-dos done?        y  yes    n  no    Esc  cancel

Enter takes a to-do to the target's own row, selected. A to-do about a merge request lands you on that merge request in the merge-request table, so the to-do list reads as an index into the dashboard you are already in.

s snoozes to this afternoon, tomorrow, or next week. A to-do you cannot act on for three days leaves today's list and comes back on its own.

The count badge

The view switcher carries a pending count, taken from the connection:

  merge requests   pipelines   ▍to-dos 14

Scope and filters

Tab reaches the to-do view, and the full pending list is there with no setup. To-dos use the same filter bar and the same pin key as everything else:

You wantFilterThen
Review requests onlyaction:review-requestedP
Mentionsaction:mentioned,directly-addressedP
One groupb to it firstP

Notifications

onNewTodo in settings sends a desktop notification when a to-do arrives. It is off by default.