Blocker Guard for Jira
A workflow validator that stops a transition while any issue blocking it is not done, and names the blockers in the error.
What it does
Jira lets you link an issue to the issues blocking it ("is blocked by"), but still lets you close it while those are open. Blocker Guard adds a validator named "Blocker Guard - blocking issues must be done" that you can put on any workflow transition. When someone makes that transition, Jira checks the issue's links. If any linked issue in the chosen relation is not resolved, the transition is refused and the open blockers are listed.
- Works in company-managed and team-managed projects.
- Default rule: every "is blocked by" issue (link type Blocks) must have a status in Jira's Done category.
- Per transition, you can choose another link type or direction, and the exact statuses that count as resolved.
- Links added on the transition screen are included in the check.
Getting started
- A Jira site administrator installs Blocker Guard for Jira from the Atlassian Marketplace.
- Open the workflow you want to protect and select the transition, for example the one into Done.
- Add a validator and choose "Blocker Guard - blocking issues must be done".
- Check the settings (the defaults suit most teams) and save the validator, then save or publish the workflow.
- Test it: link an open issue to a test issue with "is blocked by", then try the transition.
Settings
Each validator has its own settings, so different transitions can follow different rules.
| Setting | What it means |
|---|---|
| Block the transition while this issue… | The relation to check, written as it reads on the issue being transitioned, for example "is blocked by (Blocks)" or "depends on (Dependency)". Default: "is blocked by". For link types that read the same both ways, such as "relates to", either direction counts. |
| Resolved means: status in the Done category | The default. A linked issue counts as resolved when its status is in Jira's Done category (green status lozenge). |
| Resolved means: one of these statuses | Pick up to 100 statuses. Only those count as resolved, and the Done category is ignored. Use this to accept a status such as "Ready for QA", or to refuse one such as "Won't do". The list shows statuses used by active workflows. |
The workflow editor shows a one-line summary of each Blocker Guard rule, for example: Blocks the transition while any issue that this issue "is blocked by" is not in the Done status category.
The error message
When a transition is refused, Jira shows a message such as:
You can't make this transition yet: this issue is blocked by OPS-12, OPS-15, which are not done. Resolve them first, or remove the link.
Up to 10 issue keys are listed, then "and N more". If Jira cannot run the check at all, it refuses the transition with a message asking you to contact your Jira admin.
If the license lapses
If your Blocker Guard license becomes inactive, the validator lets every transition through until the license is active again. We chose this on purpose: a billing problem should never stop your team's work. The settings stay in your workflows, and enforcement resumes when you renew.
Before you uninstall
Remove the Blocker Guard validator from your workflows before you uninstall the app. Jira treats a validator whose app has been uninstalled as failed, so it would refuse every transition that carries it until an admin removes the validator. This is how Jira handles validators from all Forge apps; Blocker Guard can't change it.
Permissions
Who can do what in Jira
- Add or change the validator: people who can edit the workflow (Jira administrators, or project administrators for team-managed projects).
- Be checked by it: everyone who makes a transition that carries the validator.
Atlassian permission scopes the app requests
| Scope | Why |
|---|---|
read:jira-work | The settings page lists your site's issue link types and statuses so you can pick them. Jira reads the issue's links itself when it runs the validator. |
The app has no write permissions. It cannot change issues, links or workflows.
Data and privacy
Blocker Guard runs on Atlassian and sends no data outside Atlassian. The check is a Jira expression that Jira evaluates during the transition; no app code runs on a server. The app stores nothing: the validator settings (link type, direction and status names and IDs) are saved by Jira as part of your workflow. It uses no analytics and no cookies. Full detail is on the privacy page; security details are on the security page.
FAQ
- An issue closed even though it has an open blocker. Why?
- Check that the validator is on that transition and that the workflow was published, that the link uses the configured link type and direction (on the issue it should read "is blocked by", not "blocks"), and that the license is active.
- Does it check sub-tasks or child issues?
- No. It checks issue links only.
- Does it slow down transitions?
- No noticeable delay. Jira runs the check itself, so there is no call to an app server.
- Can I use it on more than one relation?
- Each validator checks one relation. To check several, add the validator once per relation on the same transition.
- How much does it cost?
- Pricing and trials are shown on the Atlassian Marketplace listing. Atlassian handles billing and refunds.
- I found a bug or want a feature.
- Email support@quillmarklabs.com. See the support page for what to include and response times.