Server settings for administrators, from the account menu, in Postulo's own interface #24

New issue

Closed

opened 2026-09-05 12:50:46 +00:00 by tiagoagueda · 0 comments

tiagoagueda commented

2026-09-05 12:50:46 +00:00

Owner

Observation

users with administrative scope should also have access to a dedicated server settings page from that [menu]

What exists today

The role. An administrator is a Django staff account. The only way to become one is manage.py createsuperuser at install time (README, Installing Postulo, Getting started). StaffRequiredMixin (core/mixins.py, line 28) gates exactly one thing: issuing invitations. No page lists accounts, promotes, demotes or deactivates anyone.
The Django admin is mounted at POSTULO_ADMIN_URL (default admin/) and is not linked from anywhere in the interface. It is an escape hatch, not a settings page.
Instance policy lives in the environment, next to infrastructure: POSTULO_REGISTRATION_OPEN (base.py, line 137), POSTULO_TIME_ZONE (155), POSTULO_PDF_BACKEND (184), POSTULO_CAPTURE_IGNORE_ROBOTS (192), POSTULO_DEFAULT_FROM_EMAIL (220), the SMTP host settings (prod.py, lines 54–59). Changing whether registration is open means editing .env and restarting the container.

Shape

1. A Server settings area, in Postulo's own shell, reached from the account menu (#10) — an entry that appears only for administrators, below the person's own Settings (#22). Same sidebar layout, different sections:

Section	Holds
Overview	version, Python and Django versions, database engine, PDF backend actually in use, media path and size, worker state, health
People	every account: name, email, last sign-in, administrator or not; invitations — issue, list, revoke: the existing views (`accounts:invite_list`, `invite_create`, `invite_revoke`) move here from the main navigation, decided 2026-09-05 — inviting people is user management; deactivate; make or unmake administrator — never the last one
Sign-in	registration open or invitation-only, SSO (#6), whether password sign-in stays on once SSO works
Email	what is configured, and a Send a test message button (#4's SMTP notifier makes this real)
Plugins	every installed source, notifier, store and sync with name and version — the "administration listing" `docs/PLAN.md` promised in section 7 — and whether each loaded cleanly
Capture	the `robots.txt` policy, fetch limits
Defaults	language and time zone for new accounts, the instance's name and tagline on the sign-in page

2. Which settings move, and which do not. The line is infrastructure versus policy:

Infrastructure stays in the environment: secret key, database, hosts and origins, TLS, HSTS and cookies, CSP, media serving, the admin URL, log level, SMTP credentials. These are needed before the application can start, or they are secrets, and a settings page is the wrong place for both.
Policy moves to the database: a single SiteSettings row edited from the page — registration, defaults, capture policy, instance name.
The environment wins when set. If POSTULO_REGISTRATION_OPEN is in the environment, the page shows the value read-only with "set by the environment", and the database value is ignored. Every existing deployment — the ragnar instance's .env included — keeps behaving exactly as it does today, which is what makes this non-breaking. The Compose documentation then recommends leaving policy out of .env.

3. The role, made explicit. "Administrator" is the word in the interface; underneath it stays is_staff, so nothing else changes. Two additions: the People section can grant and revoke it, and the first account created on an empty instance becomes an administrator automatically, which retires the createsuperuser step from the installation guide. createsuperuser keeps working for the person who wants it. The Django admin stays mounted and unlinked, mentioned once under Overview as the escape hatch.

4. Wiki. Accounts and invitations and Configuration are rewritten around this: what is a setting, what is an environment variable, and which wins.

Classification

Enhancement. Not breaking on one condition: environment variables keep precedence over the database, so no existing .env changes meaning. The first-account rule only affects an empty instance.

Open questions

Should SMTP host and credentials be editable from the page as well? They are secrets, but #11 will have encrypted secret storage by then. Proposal: environment only in this issue; revisit once #11 exists.
Does an administrator see other people's data? No — today they cannot, and this issue does not change that. People shows accounts, never applications, documents or contacts. Worth stating in the wiki because it is the question every shared-instance user asks.
~~Where do invitations live afterwards?~~ Decided 2026-09-05: only here, under People. The staff-only main-navigation item (base.html, line 49) is removed, and they do not appear in the account menu either (#10).

## Observation > users with administrative scope should also have access to a dedicated server settings page from that [menu] ## What exists today - **The role.** An administrator is a Django *staff* account. The only way to become one is `manage.py createsuperuser` at install time (README, *Installing Postulo*, *Getting started*). `StaffRequiredMixin` (`core/mixins.py`, line 28) gates exactly one thing: issuing invitations. No page lists accounts, promotes, demotes or deactivates anyone. - **The Django admin** is mounted at `POSTULO_ADMIN_URL` (default `admin/`) and is not linked from anywhere in the interface. It is an escape hatch, not a settings page. - **Instance policy lives in the environment**, next to infrastructure: `POSTULO_REGISTRATION_OPEN` (`base.py`, line 137), `POSTULO_TIME_ZONE` (155), `POSTULO_PDF_BACKEND` (184), `POSTULO_CAPTURE_IGNORE_ROBOTS` (192), `POSTULO_DEFAULT_FROM_EMAIL` (220), the SMTP host settings (`prod.py`, lines 54–59). Changing whether registration is open means editing `.env` and restarting the container. ## Shape **1. A *Server settings* area**, in Postulo's own shell, reached from the account menu (#10) — an entry that appears only for administrators, below the person's own *Settings* (#22). Same sidebar layout, different sections: | Section | Holds | |---|---| | Overview | version, Python and Django versions, database engine, PDF backend actually in use, media path and size, worker state, health | | People | every account: name, email, last sign-in, administrator or not; **invitations** — issue, list, revoke: the existing views (`accounts:invite_list`, `invite_create`, `invite_revoke`) move here from the main navigation, decided 2026-09-05 — inviting people is user management; deactivate; make or unmake administrator — never the last one | | Sign-in | registration open or invitation-only, SSO (#6), whether password sign-in stays on once SSO works | | Email | what is configured, and a *Send a test message* button (#4's SMTP notifier makes this real) | | Plugins | every installed source, notifier, store and sync with name and version — the "administration listing" `docs/PLAN.md` promised in section 7 — and whether each loaded cleanly | | Capture | the `robots.txt` policy, fetch limits | | Defaults | language and time zone for new accounts, the instance's name and tagline on the sign-in page | **2. Which settings move, and which do not.** The line is *infrastructure versus policy*: - **Infrastructure stays in the environment**: secret key, database, hosts and origins, TLS, HSTS and cookies, CSP, media serving, the admin URL, log level, SMTP credentials. These are needed before the application can start, or they are secrets, and a settings page is the wrong place for both. - **Policy moves to the database**: a single `SiteSettings` row edited from the page — registration, defaults, capture policy, instance name. - **The environment wins when set.** If `POSTULO_REGISTRATION_OPEN` is in the environment, the page shows the value read-only with "set by the environment", and the database value is ignored. Every existing deployment — the ragnar instance's `.env` included — keeps behaving exactly as it does today, which is what makes this non-breaking. The Compose documentation then recommends leaving policy out of `.env`. **3. The role, made explicit.** "Administrator" is the word in the interface; underneath it stays `is_staff`, so nothing else changes. Two additions: the People section can grant and revoke it, and **the first account created on an empty instance becomes an administrator automatically**, which retires the `createsuperuser` step from the installation guide. `createsuperuser` keeps working for the person who wants it. The Django admin stays mounted and unlinked, mentioned once under Overview as the escape hatch. **4. Wiki.** *Accounts and invitations* and *Configuration* are rewritten around this: what is a setting, what is an environment variable, and which wins. ## Classification Enhancement. Not breaking on one condition: environment variables keep precedence over the database, so no existing `.env` changes meaning. The first-account rule only affects an empty instance. ## Open questions 1. Should SMTP host and credentials be editable from the page as well? They are secrets, but #11 will have encrypted secret storage by then. Proposal: environment only in this issue; revisit once #11 exists. 2. Does an administrator see other people's data? No — today they cannot, and this issue does not change that. People shows accounts, never applications, documents or contacts. Worth stating in the wiki because it is the question every shared-instance user asks. 3. ~~Where do invitations live afterwards?~~ Decided 2026-09-05: only here, under *People*. The staff-only main-navigation item (`base.html`, line 49) is removed, and they do not appear in the account menu either (#10).

tiagoagueda added this to the 0.2.0 milestone

2026-09-05 12:50:46 +00:00

tiagoagueda added the

enhancement

label

2026-09-05 12:50:46 +00:00

tiagoagueda referenced this issue

2026-09-05 13:41:57 +00:00

Header, right side: avatar, full name and theme switch only; Sign out moves into an account menu #10

tiagoagueda referenced this issue

2026-09-05 13:47:37 +00:00

Two-factor authentication with TOTP and recovery codes, through allauth's mfa app #27