App technical information

App technical information

Where the app runs, whose permissions it uses, what it keeps, and how a list loads and a save reaches Jira. Issue Order runs entirely on Atlassian, with no backend and no external servers.

Where it runs

Issue Order for Jira is an Atlassian Forge app made of one Custom UI screen and nothing else: no backend function, no Forge storage, no triggers and no scheduled jobs. Jira shows that screen for Issue Order for Jira under Apps, and in a pop-up for Reorder child issues in an issue’s ••• menu (see Where to open it).

It declares no external domains, so it has no way to send anything outside Atlassian: it is a Runs on Atlassian app. It draws its own issue-type and priority icons instead of loading Jira’s icon images from your site, and follows Jira’s light or dark theme. While nobody has it open, nothing of it runs.

It acts as you

Every call to Jira is made from your browser through Forge’s requestJira, as the person signed in. The app never acts as itself or for someone who isn’t at the screen, and holds no API keys or tokens. So Jira applies your own permissions, exactly as if you ranked issues on a board by hand: spaces you can’t browse aren’t listed, issues hidden from you never load, and a change you aren’t allowed to make is refused. The app also checks Jira’s parent rules before a move is staged, so a refusal comes with its reason, not at save. The Admin guide covers the permissions.

What it stores

Nothing outside your browser. Issues are read live from Jira, and a saved order is Jira’s Rank. A few things are kept in your browser’s local storage, for that browser only. They never leave it:

The safety net is what lets a closed tab come back with Restore unsaved changes. It is cleared by a save that leaves nothing unsaved, by Discard (or Discard them on the restore banner), and by Leave without saving or Switch and discard; after 14 days it is ignored and removed. If the browser blocks storage, the switches start at their defaults and there is no safety net.

How a list loads

Each list (a space’s epics, an epic’s child issues, an issue’s sub-tasks) is read in two steps:

1. Which issues. A Jira search finds them in Rank order, asking for ids only. That way Jira returns up to 5,000 a page instead of 100, and one search covers the children of up to 50 parents.
2. The issues themselves. They are then read directly, 100 to a call and up to 8 calls at once, each with its current parent and Rank.

The second step keeps the outline exact. Search can lag behind a change: for a second or two after a re-rank it can return the old order, and just after a parent change it can still list an issue under its old parent. An issue’s own Rank and parent are current at once, so the order always comes from Rank, and an issue that just changed parent goes in the list it now belongs to. A sub-task created moments ago is picked up from its parent’s own list of sub-tasks. Deleted issues, and issues you can’t see, are left out.

A list shows up to 1,000 issues (Limits). The toolbar’s Refresh from Jira reads every list it has loaded again; coming back to the tab does it quietly, at most once a minute, only with nothing unsaved and nothing to undo, and not while a pop-up or the Sort bar is open.

How a save works

Nothing is written to Jira until you press Save changes. The save then runs from your tab, in this order:

1. Check that nothing changed. While the bar says Checking Jira…, every list the save will reorder is read again: the same issues must be there, in the same order. If anything changed, a teammate re-ranking on a board for example, nothing is written and a banner says The order changed in Jira while you were editing, so nothing was saved. Refresh loads the latest and puts your changes back where they still fit.
2. Check that ranking works, with a rank request that changes nothing. If Jira refuses it, nothing is written.
3. New parents, then new priorities, four at a time.
4. Rank, one list at a time, with the fewest moves. The list’s Rank is read fresh; if a teammate re-ranked it since the check, it is left alone and named in the result. Otherwise the app keeps the longest run of issues already in order and ranks only the others, each run straight after the issue above it, up to 50 issues per call (Jira’s limit). A list that receives issues gets this step too, because a new parent alone doesn’t change an issue’s Rank.
5. Read back. If a batch landed out of order, it is put right once, one issue at a time. Then every list the save touched is read back, and the outline shows what Jira now has.

Ranking only what has to move matters because Rank is one order for the whole site: an issue the save doesn’t need to move keeps its place on every board and backlog. At the end the status says Saved n changes. Boards and backlogs show this order too. A change Jira refuses doesn’t stop the rest; it stays in your draft with the reason. Review and save shows this from your side.

Keep the tab open

With no backend, a save runs only while your tab is open. Closing or reloading it stops the save, and what was written stays written. The app asks your browser to warn you first, but some browsers skip that inside an app’s frame. If the tab does close, the safety net still has your unsaved changes and offers them back next time.

Undo before you save, none after

Until you save, ⌘/Ctrl+Z undoes your last change and ⇧⌘Z or Ctrl+Y redoes it, up to 100 steps. After a save there is no undo, as in Jira itself: put the issues back and save again.

When Jira is busy

If Jira answers “too many requests”, the app waits as long as Jira asks (or 1, 2, 4, then 8 seconds, never more than 10 at a time) and tries again, up to four times. Only that answer is retried, because Jira didn’t act on the request. If Jira is still busy, you see Jira is limiting requests right now. Wait a few seconds, then try again.