Permissions and the admin key
A migration runs as you. It can read what you can read and write what you can write, which means the reach of a run depends on who starts it.
The admin key is the one lever that changes that, and it needs to be switched on in Confluence before the toggle in the assistant does anything.
#Who can run it
Entry point | Scope | Who |
|---|---|---|
Confluence Settings, under Capable | The whole site | Confluence administrators |
Space settings, under Capable | That one space, always | Space administrators |
#What the run can reach
Pages you cannot read are never returned by the search, so they are invisible rather than failed.
Pages you can read but not edit are found, attempted, and reported as permission failures.
Restricted pages are the usual cause of a block of permission failures in a run that otherwise went well.
#The admin key
With the admin key switch on, page counts and the run send the Confluence admin key header, so restricted pages can be read and migrated.
Two things about it. First, the switch grants nothing on its own: the key has to be activated in Confluence under Settings, Security, Admin key. Second, it expires on its own timer, so if it lapses part way through a long run, restricted pages start failing from that point onwards.
It is marked experimental in the product. Treat it as a way to complete a migration that permission failures have blocked, rather than as a default.
#A few things that catch people out
Toggling the admin key re-fetches every page count, so the counts step reloads when you change it.
Repair tools run as you and have no admin key option, so their reach can be narrower than the run that created the problem.
If a migration must cover restricted spaces, activate the key first and check its expiry against how long you expect the run to take.
#Related
It runs as you. The admin key is the exception.
