generate_and_send_welcome_mail() arrived with the mail templates, after the
read-only guards were added to the other services, and never got one. On a
read-only store it therefore rendered the mail, could hand it to the mail
server, and only failed when it tried to create the archive directory in the
member file -- surfacing a PermissionError instead of the ReadOnlyStoreError
every other write path reports.
The guard now sits at the top, next to the delivery-mode check, so nothing is
rendered, sent or written. The read-only test covers this path (and the SEPA
batch alongside it) and asserts that nothing at all was left behind: no export
file, no archive directory, no "sent" event.
Its member carries an e-mail address now -- without one the mail services bail
out for that reason, and the write the test exists for is never reached.
Note that the SEPA CSV/XML export keeps writing without a guard on purpose: it
writes to a path the board picks outside the store, which a read-only store has
no say over.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
dev gained the editable mail templates, which live in the store like everything
else -- so they follow the same read-only rules: the options dialog skips saving
them, save_mail_template() reports the store instead of a raw PermissionError,
and a store that cannot keep its own copy simply renders from the shipped
default.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The encrypted volume holding the member data can be mounted without write
access, but starting against such a store failed: the housekeeper takes a lock
file before doing anything, so its startup pass died with a PermissionError and
took the whole start with it.
The store is now probed with an actual write once at startup -- permissions,
mount options and filesystem state all matter, and only an attempt covers them
together -- and a read-only store opens as a read-only session. The housekeeper
is skipped rather than attempted, every write inside the repository goes through
one guard that reports ReadOnlyStoreError (a RepositoryError, so the dialogs
already handle it) instead of letting an OS error surface, and the services that
archive into the member file check before they start sending or rendering.
The session says so permanently: a warning banner above the tabs, "NUR LESEN" in
the window title and status bar, and refused actions explaining why. Program
settings still save -- they live in the user's config directory -- while the
store-backed ones are skipped with a notice. "Erneut prüfen" picks up a volume
that was remounted writable without restarting.
A store that was never initialized still fails, but says that creating one needs
write access.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Marcel PeterkauandClaude Opus 5