officerdev/platform
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

email extraction: plugin side built, platform untouched

Browse Source
This commit is contained in:
pastilhas
2026-08-17 23:56:39 +00:00
parent c5ed6cc32c
commit 4655d374ec
1 changed files with 15 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/email-plugin-extraction.md
+15 -2
View File
@@ -3,7 +3,10 @@
Started 2026-08-17. The runbook is `plugins/EXTRACTING-A-PLUGIN.md` and it is the authority; this file only Started 2026-08-17. The runbook is `plugins/EXTRACTING-A-PLUGIN.md` and it is the authority; this file only
records what is specific to email — the boundary, the decisions taken, and what they cost. records what is specific to email — the boundary, the decisions taken, and what they cost.
**Status: mapped, decisions taken, not yet moved.** **Status: the plugin side is built and typechecks. The platform has NOT been touched.**
Everything so far is additive, inside `plugins/email/` — which is gitignored, so the platform tree is
unchanged and email is exactly as switched-off as it was. Nothing is broken and nothing needs reverting.
The owner asked for a full extraction with no interim step ("no temporary steps"), and was explicit that The owner asked for a full extraction with no interim step ("no temporary steps"), and was explicit that
speed is not the constraint. Email is therefore NOT being switched back on in place first, even though that speed is not the constraint. Email is therefore NOT being switched back on in place first, even though that
@@ -96,7 +99,17 @@ this extraction on new platform work).
else, so this is the shape available; the alternative is a second plugin route. **User-visible change:** you else, so this is the shape available; the alternative is a second plugin route. **User-visible change:** you
will add and remove mail accounts from `/email`, not from `/settings/integrations`. will add and remove mail accounts from `/email`, not from `/settings/integrations`.
### 3. Encrypt the credentials — TAKEN ### 3. Encrypt the credentials — REVERSED, deferred to the plugin
Originally taken on the reasoning that the table has never held a row here, so encryption was free. That
reasoning only covers THIS machine — another install may have rows from before 2026-08-13, and a format
change would strand them.
The stronger argument is about verification: a pure move is checkable, because any first-install failure is
the move. A move plus a data-format change gives a failure two causes, on a feature nothing has exercised in
four days. Encryption is now the first item in the plugin's own README.
### 3b. What the original decision said — TAKEN, then reversed
`email_accounts.credentials` is jsonb holding an IMAP app password in the clear. It is encrypted through `email_accounts.credentials` is jsonb holding an IMAP app password in the clear. It is encrypted through
`officerdb/crypto` under its own `email` secret-store purpose as part of the move. `officerdb/crypto` under its own `email` secret-store purpose as part of the move.