What to know before you install Canopy.
Someone on your team has asked for Canopy. This page covers where it runs, what it can touch, what it keeps, and what happens if you remove it.
Could you install Canopy for our Jira site? It's an app that shows a project as a tree we can reshape from the keyboard, and installing it from the Atlassian Marketplace takes about a minute.
It runs on Atlassian Forge, with no servers of its own. Its makers can read the app's log and usage counters, which Atlassian hosts; the details page says what they contain. Every change it makes to work items is made as the person using it, with their own Jira permissions. Its only writes of its own are a note on the project saying it uses Canopy's hierarchy, and a regular removal of closed accounts from its archive marks.
The plan it draws is stored in Jira's own issue links and issue properties, so if we ever uninstall it, every work item and every parent-child link stays where it is. Only Canopy's own saved Views, Branches, palettes, templates and baselines become unavailable when it is removed; the Privacy Policy says how long Atlassian keeps them.
The details are at bloomlogic.co.uk/for-admins.
Where it runs
Canopy is built on Atlassian Forge. Its backend and storage run on Forge; we operate no servers, database or queue of our own for it.
Inside your Atlassian site
The app runs on Atlassian's platform, and we hold no copy of anything in your site. What we can read is the app's log and usage counters, both held by Atlassian. The log, which Atlassian keeps for 30 days, carries account IDs and work item keys, and when a card keeps disagreeing with Jira, the differing values of fields such as its status and dates; never a work item's title or description. The usage counters, in Atlassian's app metrics, are a person's first edit, their return within a week, a person opening Canopy in a week, a project's size as one of five bands, a picture exported, and the admin note copied, each only a name and the number one.
No outside connections
No outside analytics service, no error reporting, no fonts or scripts from elsewhere. Every release is checked automatically and refused if it tries to reach outside.
As the person, never above them
Work items are read and changed with the signed-in person's own Jira permissions. Where a permission is withheld, the control is disabled rather than failing. The two small marks Canopy writes as itself are listed under "In your Jira" below.
The eleven permissions, and why
These are the names you'll see on Atlassian's consent screen. Canopy asks for no admin permission.
| Permission | What Canopy uses it for |
|---|---|
read:jira-work | Show work items, their fields, comments, attachments and history, and the links between them. |
write:jira-work | Create and edit work items, change their status, add comments, upload and delete attachments, create and remove hierarchy and dependency links, and re-parent, reorder, archive, restore and delete work items, when someone does so in Canopy, always as that person. One change happens without an edit: once a project has adopted Canopy's hierarchy, opening Canopy files a work item newly created in Jira under its Jira parent, with a Canopy link made with the viewer's own permissions. Canopy itself only removes a closed account's ID from archive flags, normally once a week, on Atlassian's schedule. |
read:jira-user | Show who work is assigned to, with their name and picture. |
read:project:jira | Know which project the page is for, with its work types and statuses. |
write:project.property:jira | Remember, on the project itself, whether it uses Canopy's own hierarchy. One short value, nothing else. |
read:board-scope:jira-software | Find the project's board and show which sprint work is in. |
read:sprint:jira-software | |
write:sprint:jira-software | Move a work item into a sprint. |
write:board-scope:jira-software | Move a work item back to the backlog. |
storage:app | Keep saved Views, Branches, palettes, templates, baselines and display preferences. |
report:personal-data | Tell Atlassian, normally each week, which people Canopy holds anything for, so what it kept about a closed account is erased. |
What it keeps, and where
Descriptions never go into Canopy's storage. Titles go there only when someone saves them: a template keeps the titles of its cards, and a Branch is named after its top card unless renamed. Everything else stays in Jira.
In your Jira
Canopy Hierarchy links between parent and child, and ordinary Blocks links. A position on each card for sibling order, an archive flag holding who archived it and when, a mark on a card moved to the top level on purpose, and one value on the project saying it uses Canopy's hierarchy. Canopy writes two of these as itself, not as the person: the project value, after checking the person may edit work items there or is a project admin switching back to Jira's tree, and the regular removal of closed accounts' IDs from archive flags.
In Atlassian's app storage for your site
Saved Views, Branches, palettes, templates, baselines and preferences. A fifteen-minute change journal for live updates, about four months of Archive activity, the licence state, the account IDs Canopy holds anything for, and which usage counters have counted each person (their first-edit day and the last week counted).
In each person's browser
A cache so the page opens quickly, tied to that person's account. Display settings and a local record of errors stay with the browser itself.
If you uninstall it
Everything held in Jira stays: every work item, every parent-child link, every card's position, and the archive flags, which keep the account ID of whoever archived each item. Canopy's regular erasure stops with the app, so a person whose account closes later keeps their ID on those flags until they are removed in Jira. What lives in Canopy's app storage (saved Views, Branches, palettes, templates and baselines) becomes unavailable with the app; Atlassian says it keeps it 28 days after it deletes the app, and the Privacy Policy says when that happens and how recovery works.
The one setup step
To let people nest work freely, a Jira site admin adds one issue link type, once, under Settings › Issues › Issue linking. Canopy shows the same instructions on first open, and can copy a note for you.
| Name | Canopy Hierarchy |
| Outward description | is canopy child of |
| Inward description | is canopy parent of |
The outward phrase reads backwards on purpose. Swapped, Jira labels every Canopy link backwards across the whole site, showing parents as children, and Canopy can't detect it. Swapping the two back in the link type fixes every label at once. Without the link type Canopy still works on Jira's own hierarchy: viewing, filters, Views, rollups, field edits and reordering all work, but cards can't be nested under new parents.
Worth knowing
The things we'd want to be told before approving an app.
Deleting in Canopy is deleting in Jira
Canopy always asks first and lists what will go. A deleted card takes its whole Canopy branch with it, every card beneath it, and can't be undone. That goes further than Jira, where a story under a deleted epic survives. People without the Delete Issues permission can't delete from Canopy at all.
Adopting an existing hierarchy writes links into Jira
When a project already uses Jira's parent field, Canopy shows that hierarchy straight away. Choosing Adopt writes one Canopy link per parent-child pair so the tree can be reshaped freely. The links are visible in Jira. A project admin can switch the project back to Jira's tree in one step, from More (⋯, top right) ▸ Set up ▸ Switch to Jira's tree…; nothing is deleted and the links are kept.
Three shared records don't yet respect issue-level security
The record behind Recent changes, the Archive activity record and kept baselines can show someone excluded by an issue security level that a work item exists, where it sits in the tree and when it changed. A baseline kept on such an item can also reveal its name, when it was kept and by whom, so a baseline's name should not carry restricted wording. None of them automatically copies a work item's title or contents. The main tree, and a baseline's comparison, follow each person's Jira permissions.
Billing counts every licensed user
Like every Marketplace app, Canopy is priced by the number of licensed users on the site, not by who opens it. See pricing.