Blocked, blocking and related issues

GitLab and GitHub both let you say that one issue blocks another. GitGumbo reads those links and shows them on your cards, so you can see what is held up and what is holding things up without opening each issue. It also shows the plainer "relates to" links, in a quieter chip of their own.

The two chips

• Blocked is a red chip with a slashed circle and a number: this issue is blocked by that many issues. Occasionally the provider says an issue is blocked without giving a count, and the chip then shows no number.
• Blocking is a violet chip with an arrow leading away from a bar, and a number: this issue blocks that many issues.

A card can carry both. The chips show in both Full and Compact density, and they don't appear at all when there is nothing to show.

GitGumbo shows what the provider reports. It doesn't recount the links or drop closed ones, so if the provider still counts a closed blocker, so does the chip.

Where the links come from

• GitLab: linked items of the type "blocks" or "is blocked by". GitLab only stores these links on its paid tiers. On GitLab Free it refuses to create them, so a GitLab Free project never shows these chips. That's GitLab's limit, not your GitGumbo plan.
• GitHub: issue dependencies, the "blocked by" and "blocking" relationships on an issue.

See the linked issues

Point at a chip, or tab to it, and a panel opens listing the linked issues. You can move the pointer into the panel, and it closes shortly after the pointer leaves both.

Click the chip (or press Enter or Space on it) and the panel opens with focus inside it, so you can tab through the links. To close it, click the chip again, press Esc or click anywhere outside. Scrolling the board also closes the panel; scrolling inside the panel doesn't. On a touch screen, tap the chip.

Each row shows:

• the issue's title, which opens the issue in a new tab;
• its reference, such as #12;
• the word closed if that issue is already closed. A closed blocker usually means a link someone forgot to remove;
• where to find it on this board: In and the name of the column the card is in, even when your filters hide it or its column is collapsed, Not on this board when the board hasn't loaded that issue, for example an issue that closed a while ago, or In another project for a named issue from another project.

Linked issues in other projects are named only when you can read them there. The row shows the issue's title, reference and link when that project is also monitored in the firm you are working in and your own access lets you read that issue there. Otherwise it shows "Issue in another project", with no title, no number and no link. GitGumbo checks this with your access, not the account that syncs the board, so two people can see the same row differently. A named issue's title and link are as they were when the card last synced, not live. This applies to both providers, including a GitHub link to another repository. On GitLab, if your role in the project doesn't let you see its confidential issues, every linked issue shows as "Confidential" instead, wherever it is. The chip's number still counts them all.

The panel lists up to 10 issues, then "and N more". If the provider's count is higher than the list it returned, the panel says how many more aren't listed instead: those issues may be in a project the connected account can't access, or the provider's count may be out of date. Two other messages can appear instead of the list:

• "Details will appear after the next sync." GitGumbo knows the count but hasn't fetched the list yet.
• "No details were returned for these blockers" (or "these issues"). The provider gave a count but no details, which usually means the linked issues are in a project the connected account can't see.

Highlighting and lines

While a panel is open, the linked cards on this board get an accent ring and every other card fades. Thin lines join the card to each linked card.

• If a linked card is off the edge of the visible board, its line stops at the edge with an arrowhead pointing the way and a #number label. The arrowhead shows where the card is, not which issue blocks which.
• If a linked card is scrolled above or below its own column's visible list, the line stops at the top or bottom edge of that list, on the side nearest the card you started from, with an arrowhead pointing straight up or down and a ↑ #number or ↓ #number label. The label is a button: click it (or press Enter or Space on it) and the column scrolls to the card and flashes it, smoothly when motion is allowed and in one jump under reduced motion; if the column alone can't show the card, the page scrolls the rest of the way. Focus stays where it was. A line ending at a column edge stays up briefly after the pointer leaves the chip, and while the pointer is on the label, so you can reach it. Once the card is in view the line is redrawn to the card and stays for a moment before it clears.
• If a linked card is in a collapsed column, one line goes to the column's strip, and the strip shows how many linked issues it holds in place of its usual count. Collapsed columns with no linked issues fade too.
• Only cards on this board light up. Issues in other projects, closed issues and cards hidden by your filters appear in the panel but get no ring and no line.

A panel opened by pointing clears its highlight as soon as you scroll. A panel opened by clicking keeps the rings and lines while you scroll the board to find the linked cards; press Esc or click outside to clear them.

Relates to

On GitLab and GitHub, an issue can also be linked to another as "relates to", which says the two are connected without saying either one holds the other up. GitGumbo shows these links as a Relates to chip: a plain, neutral chip with a border, a link icon and a number, the count of issues this one relates to. A screen reader hears "Relates to 2 issues". The link goes both ways, so both cards show it.

• It is quieter on purpose. Blocked and Blocking are about flow: something can't move until something else does. A relates-to link is only an association, so its chip takes the board's neutral colours, not red or violet, and it doesn't count toward the Blocked/Blocking filter or the Blocking most sort.
• Only real links. GitGumbo shows the "Relates to" links you make in GitLab or GitHub. It never guesses a link from issues that mention each other.
• It works on GitLab Free. "Relates to" is the one link type GitLab Free lets you create, so on a GitLab Free project it is the only link chip you will see.
• 10+. GitGumbo reads the first 10 related issues. If there are more, the chip reads 10+ and the panel ends with "More not listed. GitGumbo shows the first 10."

Point at the chip or click it to open the same kind of panel as the other chips, listing the related issues. The related cards on this board get the accent ring, and the lines to them are dashed and muted, so they never read as a blocking link. As with the other chips, the lines show only while you point at the chip or after you click it, never all the time.

The chip shows in both Full and Compact density, and only when the issue has at least one relates-to link.

Turn it off

Settings → Board display → Show 'Relates to' links on cards. Turning it off hides the chip and its lines on every board, for you only. It's saved to your account. Sync keeps reading the links either way, so turning it back on shows them straight away, without waiting for a sync.

Filter and sort

The filter bar has a Blocked/Blocking toggle. It shows every card with either chip, red or violet, so a blocker stays on screen beside the cards it holds up. Relates to links don't count. The toggle only appears when at least one card on the board has one of those chips. Like every filter, it is saved in the page address, so a link you share keeps it.

There is also a Related toggle, which shows only the cards with a Relates to chip. It's separate from Blocked/Blocking, appears only when at least one card has a relates-to link, and is hidden while Show 'Relates to' links on cards is off.

Each column's sort menu has Blocking most, which puts the issues that block the most others at the top. Pick it again to reverse the order. Cards whose links haven't been read yet always sort last.

When a new link shows up

Links are read by sync, the step where GitGumbo's server fetches your project from GitLab or GitHub. The board then picks up the change on its next refresh from GitGumbo, every 5 seconds on Pro and every 30 seconds on Free.

• GitLab: adding or removing a link, of any type, counts as a change to the issue, so the next background sync picks it up: every 5 minutes on Pro and every 15 minutes on Free, or at most every 30 minutes for a project with 1,000 or more open merge requests.
• GitHub: adding or removing a dependency or a "relates to" link doesn't mark the issue as changed, so the ordinary background sync can't see it. GitGumbo re-reads every open issue's links once an hour. To see a change sooner, choose Full Sync from the Sync button's menu, or use the ↻ on the card.

The ↻ on a card, Sync and Full Sync work on every plan, on both providers.