Rules

Rules build part of a tree from Jira data and keep it current. A hierarchy can mix rows placed by rules with rows you placed by hand.

How rules work

A rule is a row of the tree and applies where it sits: a rule at the top level works on the whole hierarchy, and a rule under a row works only on what sits under that row. Rules run in the order they are listed, so an "add" rule comes before the rules that extend, filter, group or sort what it added.

The app builds rule results in the background and refreshes them when issues change in Jira. When a new issue matches a rule, or an issue moves in Jira, it shows up in its place shortly after. Everyone who opens the hierarchy sees only the issues Jira lets them see.

To change rules, you need Automate access to the hierarchy. Your Jira admin can also limit who may change rules across the whole site in Automation permissions.

The Rules panel

Open Panels in the hierarchy's header and choose Rules. When the hierarchy has rules, the menu shows their count, such as Rules (3).

The panel lists the rules in order, each with Edit and Remove. At the top, a line says whether results are up to date or still updating, and Refresh results builds them again on request.

To add a rule, select Add rule, pick the Rule type and fill in its fields. New rules go at the top level. To put one under a row instead, focus that row first and tick Apply under "…" only. Rules can't go inside the results of other rules.

Rule types

Adding issues

A query that depends on who runs it, such as one with currentUser() or recently viewed issues, is worked out for each person when they open the hierarchy. This is slower, and the form warns you about it.

Bringing in related issues

Filtering, grouping and sorting

Rules filter by JQL and by text only. Other filters, such as by field value, sprint or tree query, are transforms, which change only your own view. To sort or group by a column such as a formula or a total, use that column's header menu.

Limits and notices

The site's admins set how large rule results may grow: rows in one hierarchy, issues one rule may add, the deepest level rules may fill, and how many levels one "add children" or "add links" rule may add. A hierarchy holds at most 2,500 issues and runs at most 30 rules. Of those, at most 5 may be rules that read every row they reach: Keep issues containing text, Group by field, Group by linked issue and Sort by field. A rule past either cap doesn't run and says so.

When a rule reaches a limit, the app keeps what it built so far, and a notice next to the row count names the limit, for example "some rule results were left out (row limit reached)". The notices for the 2,500-issue limit and the time limit show to everyone. A row, issues-per-rule, depth or level notice shows only to people who can see at least one of the issues it left out. The Rules panel marks the rule that stopped. Admins can raise the limits in Rule limits.

Moving rows that rules placed

Rows that rules placed come from Jira data, so you can't move them freely. When you move one, the app changes that data in Jira on your behalf, and the rules then show the issue in its new place:

• Moving an issue up or down among its siblings ranks it in Jira. A list sorted by another field keeps that order.
• Moving an issue to another group of the same grouping sets the grouped field. A status changes through the workflow transition that leads there, and a sprint through Jira's sprint and backlog actions.
• Moving an issue under another issue changes its parent, or its link, so that it matches how the other issues there are placed.

The app checks a move before it changes anything and refuses one it can't carry out cleanly, such as a move between groups made by name or by linked issue, or one that changes a field like issue type or project. For a link, the app creates the new link before it removes the old one. A line under the toolbar says what changed in Jira and names any issue Jira refused, with the reason.

Rows placed by hand and rows placed by rules can't be moved together.

Changes inside rule output

People with Control on a hierarchy can let people with Edit adjust what the rules placed. The setting is Let people with Edit change rule output by hand, on the Access tab of the hierarchy's settings. With it on, you can:

• move rows the rules placed among their siblings, without ranking them in Jira (marked ↕);
• hide issues the rules placed;
• place rows of your own, such as folders or other issues, under rows the rules placed.

None of this changes Jira. The Inside rule output button in the toolbar shows how many changes there are and opens a panel that lists them. There you can show hidden issues again, Clear my changes, or Clear all changes… made by anyone. If you turn the setting off, the changes are kept but have no effect until you turn it on again.

A row placed by hand whose rule row no longer exists shows at the top level, marked ⇡.

Rule presets

A preset is a saved set of rules you can apply in one step at another place, in the same hierarchy or another one. At the bottom of the Rules panel, Save rules as a preset… keeps the rules at the top level, or those under the focused row. Tick Share with everyone to let others use it. They see the rules but nothing else from your hierarchy.

To use a preset, pick it under Presets and select Apply preset. Its rules go through the same checks as rules you add by hand. A rule that no longer fits the site, for example one that names a deleted field, is left out with a note.

The Rovo agent can also suggest rules from a description in plain words.

Questions about the app? Write to info@plugincraft.ca.