ADMINISTER
ADMINISTER = 'administer strata'
The permission that grants everything.
Decides whether an account may run a particular restore.
Rollback is not one permission. Restoring one node and replacing every table are different operations with different blast radii, and a site that lets an editor undo their own mistake should not thereby let them replace the users table. So the check is per REALM, and a plan spanning three realms needs all three.
Config rollback is treated as privilege escalation. Configuration includes user.role.* and
filter.format.*, so anyone who can restore config can restore a state where they had more
permissions than they do now. That is not a reason to forbid it - it is a legitimate recovery
operation - but it is a reason the permission is marked restricted and is never implied by content
rollback.
Two-person approval is opt-in and applies to the destructive scopes. When it is on, the account that requested a restore cannot be the account that approves it. That is checked here rather than in a form, so a drush command and a REST call get the same rule.
REQUIRES_APPROVAL = [\Drupal\strata\Journal\Realm::TABLE, \Drupal\strata\Journal\Realm::SCHEMA]
Realms whose restore is destructive enough to be eligible for two-person approval.
A table replacement removes rows and a schema change alters structure; neither is undoable by anything short of the pre-restore snapshot.
forRealm(\Drupal\Core\Session\AccountInterface $account, \Drupal\strata\Journal\Realm $realm) : \Drupal\Core\Access\AccessResultInterface
Whether an account may restore one realm.
| \Drupal\Core\Session\AccountInterface | $account | The account. |
| \Drupal\strata\Journal\Realm | $realm | The realm. |
The result, cached per permission so a page rendering many restore links does not re-check.
forPlan(\Drupal\Core\Session\AccountInterface $account, \Drupal\strata\Restore\RestorePlan $plan) : \Drupal\Core\Access\AccessResultInterface
Whether an account may apply a whole plan.
Every realm the plan touches has to be granted. A plan the account can only partly restore is refused rather than silently narrowed: restoring half of what was confirmed leaves the site in a state nobody chose.
| \Drupal\Core\Session\AccountInterface | $account | The account. |
| \Drupal\strata\Restore\RestorePlan | $plan | The plan. |
The result.
toApprove(\Drupal\Core\Session\AccountInterface $approver, int|null $requestedBy, \Drupal\strata\Restore\RestorePlan $plan) : \Drupal\Core\Access\AccessResultInterface
Whether one account may approve a restore another requested.
| \Drupal\Core\Session\AccountInterface | $approver | The account approving. |
| int|null | $requestedBy | The account that requested it, or NULL for an unattended request. |
| \Drupal\strata\Restore\RestorePlan | $plan | The plan. |
The result.
legacyPermission(\Drupal\strata\Journal\Realm $realm) : string
The broader permission a realm also answers to.
The named permissions in strata.permissions.yml are what an administrator recognises -
"roll back content", "roll back configuration" - and the generated per-realm ones are what a
fine-grained site uses. Either grants the realm.
| \Drupal\strata\Journal\Realm | $realm | The realm. |
The permission.