User administration¶
User accounts are managed on the admin page under Users. Creating, changing
and deleting requires the admin role.
Creating an account¶
A new account needs a username and an e-mail address. You do not set a password: the person receives an e-mail with a link and chooses their own password, so only they know it. The link is valid for 72 hours and works once.
If it has expired or the mail did not arrive, send the invitation again with Send invitation on the account's page.
Roles¶
Anton keeps the roles untranslated — in the selection list they appear exactly like this:
| Role | May |
|---|---|
blocked |
Nothing; access is barred |
user |
See the catalogue like the public, plus profile and notifications |
user_intern |
In addition, blocked content, locations (view only), loans, original media |
loan_admin |
In addition, manage loans |
editor |
Catalogue: create, change, move, delete (including locations); import; media |
admin |
Settings, forms, user accounts, export, statistics |
Each role includes the rights of the one below it.
Block accounts rather than delete them
blocked is the right approach for accounts that are no longer used. When
an account is deleted, the references are lost — the description control
then shows a name without an account.
Superusers¶
Beyond admin there are superusers for system-related interventions: field
types, value lists, protection periods, descriptors,
logs and the merging of places.
Superuser is not a role and cannot be assigned in the user administration. What counts is a separately maintained list of usernames; it permanently contains the k & r accounts and can be extended via a setting.
Releasing individual areas¶
An account with the user role can be granted access to particular branches —
for researchers who may work on a blocked holding without seeing everything.
To do so, the IDs of the units of description are entered in the released IDs field as a comma-separated list. An ID always stands for the entire branch below it — the unit itself and all subordinate ones.
Within that branch the account sees everything user_intern sees: blocked
descriptions and drafts, media under protection period and blocked media, and
the internal detail view. Outside the branch it sees what guests see.
API tokens¶
For access via the API, tokens can be generated per account, each with a name and, if needed, an expiry date. A token is shown only once, right after it was created; the detail page then lists name, last use and expiry and lets you revoke single tokens. A token receives the rights of the account; a token for read access therefore belongs to an account with a correspondingly restricted role, not to an administration account.
Login procedures¶
Besides username and password, two-factor authentication and passkeys are available depending on the installation — see Authentication.