Managing users

Settings → Administration. The tab is shown only to an account whose role is admin; Open registration says where that role comes from and why the tab may not be there at all.

One row per account

One row per account on the instance, oldest first:

Column	Contents
User	the username, the full name and the email, with (you) on your own row
Role	Admin or User
Security	2FA on or 2FA off, as a checked or a struck-through shield
Created	the day the account was opened
Last sign-in	the newest session’s date, and how many sessions are still live
API keys	how many of its keys have not been revoked
Accounts	how many wealth accounts it owns
Transactions	how many operations across those accounts

A session counts while its refresh token is neither revoked nor expired, so that figure is live sessions rather than sign-ins ever made. An account that has never signed in reads Never.

Naming an administrator

Under the role of every other real account there is one action: Make admin on an ordinary user, Remove admin on an administrator. Each asks you to confirm and names the username. An administrator can do everything you can on this tab, including remove the role from you.

Two changes are refused:

• Your own role. You cannot change your own role. Have another administrator do it.
• The last administrator. The last administrator cannot be made an ordinary user.

This is also how an administrator who wants to leave does so: name somebody else, then delete your own account from Settings → Data.

Deleting an account

The bin at the end of a row asks you to confirm, names the username, and deletes that account with everything it owns. There is no undo, and nothing is exported on the way out: if the data matters, take an export from that reader’s own session first.

Two deletions are refused outright:

• Your own. You cannot delete your own account here. Delete your own from Settings → Data, which asks for your password.
• The last administrator. The last administrator cannot be deleted.

The automatic promotion at start

On every start the application counts the administrators, and when there are none it promotes the oldest account on the instance and says so in docker compose logs app:

Promoted "<username>" to admin (no admin existed)

That is how a single-reader install older than this screen ends up with one. The check is skipped rather than fatal when the database is not up yet, and runs again at the next start.

The routes behind the tab

Route	What it does
GET /api/admin/users	the table above
PUT /api/admin/users/:id/role	{ "role": "admin" } or "user", with three refusals
DELETE /api/admin/users/:id	one deletion, with the two refusals
GET /api/admin/settings	the two switches on this tab
PUT /api/admin/settings	moves whichever switch was sent

All five answer 403 Administrators only to anyone else, whatever the session carries.