mix
75207f0d1e
[1.0.0]
Added:
- A **Delivery log** on each delivery's page (`/deliveries/{id}`): the
- A **History** block on the same page: the journal's two timestamps stated as
Fixed:
- Postfix config: copy TLS cert/key from the (often `:ro`, host-owned) mount
- Postfix config: allow `maillog_file` under `/data` via
- E2e: read `/data/setup-token` via `docker compose exec` (file is `0600`
- Entrypoint: check `SELFPOST_HOSTNAME` before `/data` setup (so a bad identity
- E2e gate: wait for host-published `/healthz` before panel setup, and stop
… (3 more in CHANGELOG)
Changed:
- Document what `.spbk` and `.spde` stand for (SelfPost backup / SelfPost domain
- Docs aligned with the code: setup URL is `/setup/<token>` (README and
- Full backups no longer carry `/data/log`. It is Postfix's raw log plus its
- Monitoring screens (status, mail queue, system log, deliveries) use adaptive
- Documentation package consolidated into `docs/development.md`: Documentation
… (4 more in CHANGELOG)
[1.0.1]
A documentation and packaging release: no change to the mail path, the database, or the on-disk layout. Upgrading is a tag bump.
Added:
- `SECURITY.md` — how to report a vulnerability privately (GitHub private
- [docs/plans/](docs/plans/) — one document per agreed extension: the optional
Changed:
- The panel's **Account** entry is now called **Settings** — nav link, page
- The signed-in name in the panel's nav is now labelled `User:`, so it reads as
- [docs/product.md](docs/product.md) reframes the future line: the inbound
- [docs/security.md](docs/security.md) is now in English, matching the rest of
- The README documentation table now points at `SECURITY.md` for reporting a
… (2 more in CHANGELOG)
Fixed:
- The panel's static assets are served with a content ETag and
Squashed CHANGELOG sections: [1.0.0], [1.0.1].
Full detail: CHANGELOG.md (1.0.0, 1.0.1).
2.1 KiB
Plan: web-split (splitting internal/web)
Status: agreed
Version: 1.x; an internal refactor, it does not force a break on its own.
What this is
internal/web is the project's largest package: ~50 files (templates and
static assets included), ~25 .go files and ~4000 lines of Go, with the
handlers for every panel section, sessions, security headers, origin checking,
form validation and template rendering all sitting in one flat namespace.
The candidates to split out are web/handlers and web/auth, or a cut along
the panel's own domains.
Why now
At its current size the flat package reads fine: the file names
(handlers_domains.go, handlers_apps.go, handlers_monitor.go) do the work
directories would, and splitting would force exporting what is package-private
today — widening the internal API for cosmetics.
It starts to pay off once the package grows: domain-admin and inbound-relay both add code to it — the role brings authorisation into every handler, the inbound relay brings its own pages and handlers for inbound domains. The refactor is cheaper before that growth than after it.
Recommended order
web-split → domain-admin → inbound-relay (see the roadmap).
- web-split — lay down the package structure (including a place for
web/auth) while there are no cross-cutting edits from the role and no new inbound handlers. - domain-admin — authorisation in every handler builds on a package layout already chosen.
- inbound-relay — a new vertical slice; easier to add to an already split package than to refactor alongside the two features before it.
The order is a recommendation, not a blocker.
Done when
The decision is made deliberately when the work starts — either the package is
split along the chosen scheme, or it is settled that it stays flat. After a
split: build/vet/test green, the panel's behaviour unchanged.
Risks
- Splitting too early — a superfluous internal API and churn with nothing to show for it;
- leaving it until after the growth — a harder refactor, tangled up with the features.