Space panels
Not every panel concerns the whole site. One team usually wants one table on its own work items, and asking a Jira administrator for it is a detour that gets longer the bigger the site gets. Whoever administers a space can now build those panels themselves, in that space's own settings, without touching anything outside it.
Who may build them
The permission is Jira's Administer Projects on that space, the same one that unlocks the rest of Space settings. Nothing else is needed, and nothing is taken on trust: every time a panel is created, changed, reordered or deleted, Linker asks Jira whether the person on the line holds that permission on this space. The answer is Jira's own and always current, so a page somebody left open after losing the permission writes nothing.
A Jira administrator holds the permission everywhere and can work either way: inside a space's settings like anybody else, or in the admin area, which additionally lists every space panel of the site. See The Space panels page.
Where the page is
- Open the space and go to Space settings.
- Choose “Linker Panels” in the settings sidebar, under Apps.
- Create a panel with the button above the table. The page lists the panels of this space and nothing else: no global panels, and none belonging to another space.
What you can build there
A space panel is an ordinary panel definition: the same editor, the same columns with their live preview, the same JQL filter with its live match count, and the same options for progress bar, page size, inline linking, status changes and viewer columns. Work item panels explains every part. Only three of them behave differently inside a space:
| Part | How it differs in a space |
|---|---|
| Space | Fixed to the space you are in, and not editable. The scope block says so in place and offers only the work types, which narrow the panel further inside the space; an empty list means all of them. |
| Content | Two kinds instead of three: the native Jira links of the link types you pick, each with its own direction, or the work items from a JQL query, which need no links at all. A Linker field is not offered, see below. |
| The list | Shows this space's panels only, and dragging a row reorders them among themselves. See The order the sections appear in. |
Everything else is the panel you already know: give it a name, pick the content, narrow it with JQL if you want to, choose the columns, and it renders as its own section on every work item of the space it covers.
Why a field panel is not offered here
A field panel does not stand on its own. It hangs on a field context, Jira's way of giving one custom field different rules per space, and a context is global configuration: it can span several spaces, it decides what the picker suggests and which links get written, and changing it changes the field for everybody who uses it, not only for the space you administer. Handing that out with a space's permission would let one space's administrator reach into another space's configuration through the back door. So the content selector in a space offers link types and queries, and not the field.
If a space wants a field panel, ask a Jira administrator for it. They build it as a global panel with a scope that covers exactly your space, or bound to the field context that already does, and the result is the same section on the same work items. It then belongs to them, which is the honest answer, because the configuration behind it belongs to them too.
What a space administrator cannot do
- Another space's panels. They are neither listed nor editable, and no request reaches them. A panel already built cannot be moved to another space either.
- The global panels. They do not appear in a space's settings, and an attempt to change one is refused, including an attempt that names a global panel's id directly.
- A field panel. Not offered, for the reason above.
- The order of anything but their own. Dragging inside a space rearranges that space's sections and nothing else.
- The Fields page and the field configuration. Both stay where they were, with the Jira administrator. Delegation is about panels, not about fields.
The order the sections appear in
A work item shows one Linker panel with one section per matching definition, and the order of those sections is fixed:
- The global panels first, in the order set on the Global panels page.
- Then the panels of the space the work item lives in, in the order set in that space.
Panels bound to any other space do not render at all, whatever their scope says. The two lists are ordered independently, so reordering inside a space can never move a global panel or a panel of another space, and a space administrator cannot push their own sections above the site-wide ones.
The Space panels page
Linker's admin area, under Jira Settings (gear) → Apps → Linker, has three pages: Fields, Global panels and Space panels. The third one lists every space bound panel on the site in one table, so a Jira administrator can see what the spaces built, and repair it, without being a member of every space. The Spaces column names the space each panel belongs to, and the row says who created it.
There they may edit and delete any space panel: fix a JQL filter that has stopped matching, correct a column set, remove a panel nobody wants any more. Two things they may deliberately not do:
- Move a panel to another space.
- Turn a space panel into a global one.
- Create a space panel from here. The page has no create button. A panel is bound to the space its call arrived from, and this page belongs to no space, so anything built here would come out global. To build one for a space, open that space's settings.
Either would take a panel away from the people who built it and leave it half owned, with no clear answer to “whose panel is this?”. So every panel keeps its owner: a global panel belongs to the Jira administrators, a space panel to the space it was built in. When a space panel really should apply site wide, build a global panel for it and delete the space one. That is one deliberate act instead of a silent change of ownership.
Switching delegation off
Delegation is on from the start. A Jira administrator who does not want it switches it off with the single toggle on the Space panels page: Space administrators may create panels in their own space.
Off means off everywhere, not only in the interface. The switch is read where the permission is decided, on every single write, so a call that goes past the page is refused exactly as the page is. What it does not do is break what already exists: space panels that were already built keep working and keep rendering on their work items. A Jira administrator can still edit and delete them on the Space panels page, and switching delegation back on brings the page back in every space. Both directions are recorded in Recent app activity.
Who created a panel
Every panel records who built it, and the Space panels page shows that name under the panel's name. It answers the first question a Jira administrator has about a panel they did not build themselves: who to ask about it.
What is stored is the Atlassian account id and nothing else. The display name is looked up from Jira at the moment the list is drawn, so a renamed person reads correctly straight away, a deactivated account simply has no name to show, and no personal data is kept a second time. Panels that existed before this arrived have no author recorded, and they say nothing rather than guessing. See Data & privacy.