Gather the privacy settings into a section of their own #200

New Issue

Closed

opened 2026-09-02 05:24:01 +00:00 by jcoffey-dev · 0 comments

jcoffey-dev commented

2026-09-02 05:24:01 +00:00

Owner

What moved

Six settings, into Privacy & safety, in three groups:

Group	Holds
Remote content	Remote images policy, and the senders trusted with them
Read receipts	Requesting them, and answering them
Before it happens	Undo-send window, attachment reminder, confirm-before-delete

General keeps what it is actually about and is 31 lines shorter (244 → 213).

Nothing moved in storage. Settings are a flat object in settings.json; sections are only how they are grouped on screen. No migration, no key renames, no sync concern.

The boundary against Security & sessions

Worth stating explicitly, because two similar words adjacent in a nav is how a menu becomes something people hunt through:

Security & sessions — credentials and access: password, two-factor state, app passwords, live sessions.
Privacy & safety — how the app behaves towards the reader and towards senders: what loads, what leaks, what asks first.

Icon is EyeOff, deliberately not a second shield.

Two things beyond the move

Trusted senders are now reviewable. A sender was added to the remote-image allow-list from a message, and could then only be removed by finding another message from that same sender. They are listed here and withdrawable one at a time. This is new behaviour rather than a move — flagging it since it was not in the original scope.

Fixed a false statement in General's lead. It said settings are "stored in this browser", which is only true when the server has no FileNode support. They normally live in the account's own Files and follow it between devices — so the sentence contradicted the feature it sat above.

Testing

6 component tests, including the one that matters for a move like this: that no setting is reachable in neither section. A setting that stops being reachable is still stored and still applied, which is worse than leaving it where it was. Also asserts the write-through still lands on the same stored keys, and covers the trusted-sender add/remove.

Suite green: web 609, server 110, typecheck clean.

Verified

Section renders and the /settings/privacy deep link resolves directly — checked in the running app against the mock.

The trusted-sender chip list was not seen rendered: I could not get a message to open under browser automation this run. It reuses .chip/.chip-x, already proven by the composer's recipient chips, and both add and remove are covered by tests — but it is worth one look before merge.

Note

This is a prerequisite for the three sender/link warnings, which land in this section.

Merged 2026-09-01 as coffey-labs/ihasmail@4c54eb74f9

_{Rebuilt from: git history, session transcript.}

General had grown five unrelated headings and had become where anything without an obvious home ended up. Remote images were filed under "Reading", the read-receipt policy under "Composing", the undo-send window beside the default message format. They are the same kind of decision — what reaches a sender, and what asks before something happens — and they were the hardest settings in the app to find. ## What moved Six settings, into **Privacy & safety**, in three groups: | Group | Holds | | --- | --- | | Remote content | Remote images policy, and the senders trusted with them | | Read receipts | Requesting them, and answering them | | Before it happens | Undo-send window, attachment reminder, confirm-before-delete | General keeps what it is actually about and is 31 lines shorter (244 → 213). **Nothing moved in storage.** Settings are a flat object in `settings.json`; sections are only how they are grouped on screen. No migration, no key renames, no sync concern. ## The boundary against Security & sessions Worth stating explicitly, because two similar words adjacent in a nav is how a menu becomes something people hunt through: - **Security & sessions** — credentials and access: password, two-factor state, app passwords, live sessions. - **Privacy & safety** — how the app behaves towards the reader and towards senders: what loads, what leaks, what asks first. Icon is `EyeOff`, deliberately not a second shield. ## Two things beyond the move **Trusted senders are now reviewable.** A sender was added to the remote-image allow-list from a message, and could then only be removed by finding *another* message from that same sender. They are listed here and withdrawable one at a time. This is new behaviour rather than a move — flagging it since it was not in the original scope. **Fixed a false statement in General's lead.** It said settings are "stored in this browser", which is only true when the server has no FileNode support. They normally live in the account's own Files and follow it between devices — so the sentence contradicted the feature it sat above. ## Testing 6 component tests, including the one that matters for a move like this: that no setting is reachable in *neither* section. A setting that stops being reachable is still stored and still applied, which is worse than leaving it where it was. Also asserts the write-through still lands on the same stored keys, and covers the trusted-sender add/remove. Suite green: web 609, server 110, typecheck clean. ## Verified Section renders and the `/settings/privacy` deep link resolves directly — checked in the running app against the mock. The trusted-sender chip list was **not** seen rendered: I could not get a message to open under browser automation this run. It reuses `.chip`/`.chip-x`, already proven by the composer's recipient chips, and both add and remove are covered by tests — but it is worth one look before merge. ## Note This is a prerequisite for the three sender/link warnings, which land in this section. **Merged** 2026-09-01 as coffey-labs/ihasmail@4c54eb74f97a <sub>Rebuilt from: git history, session transcript.</sub>

This repo is archived. You cannot comment on issues.

1 Participants

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: coffey-labs/ihasmail-github-archive#200