4 Commits

Include renames

Author	SHA1	Message	Date
jcoffey-dev	9fcf4812f3	Notifications with the app closed, for every signed-in account ... Second of three for background push across accounts (multi-account spec, MA-8 part 2). Turning on "Notify me even when inbuxa is closed" now registers this browser in every signed-in account, each through its own session (the route from the previous change), and renewal keeps them all current. GET /api/auth/accounts says which mail account each session is, so the subscription can name it. The remembered endpoint is kept per account, and survives the clean-up that follows switching accounts. The service worker is told who the other accounts are. A push for one of them is titled with that account's address, shown even while a tab is focused (the tab only shows the front account's mail), and its Mark read and Archive act through that account's session. Clicking it brings that account to the front and opens the message. While push is on, the tab's own polling of other accounts stops notifying, so nothing arrives twice. Signing out of one account removes this device's subscription there only; signing out of all, or turning push off, removes every one. Also fixes where every background notification opened: the worker linked to /mail/inbox/<thread>, and the route takes a mailbox id there, so a click landed on the inbox list with "That folder no longer exists". The worker now gets each account's inbox id and links to the message. Checked end to end in Chrome against a local server with two accounts: both registered and verified, a message to the account not in front showed a notification under its address, and clicking it switched accounts and opened the message. No new strings. typecheck, tests (web 1547, server 279) and build pass.	2026-10-05 20:38:44 -07:00
jcoffey-dev	6b979c5ac7	A narrow route to another signed-in account, for its push subscription ... First of three for notifications with the app closed, for every signed-in account (multi-account spec, MA-8 part 2). No behavior changes yet. A JMAP push subscription belongs to whoever signs the request, so an account that isn't in front can only have one registered, verified and renewed through its own session. POST /api/auth/accounts/<sessionId>/jmap forwards to the mail server as that session, when it is one of this browser's other accounts, and only for PushSubscription/get and /set, Mailbox/get, and Email/set limited to keywords and mailboxIds updates (what a notification's Archive and Mark read need). Anything else is 403; the account in front, or a session this browser doesn't hold, is 404. Its OAuth token is renewed first if due. The browser already holds the session, so nothing new becomes reachable. On the web app side the push helpers (list, create, extend, destroy, verify) take a JMAP caller, defaulting to the account in front exactly as before, and lib/notify/otherAccount gives the caller for another account through the route. Tests: the allowlist, the route end to end with two accounts (allowed, refused, front and unknown sessions), and the caller. The accounts test file now raises LOGIN_RATE_LIMIT, since it signs in more often from one address than the default allows. typecheck, tests (web 1543, server 278) and build pass.	2026-10-05 20:24:18 -07:00
jcoffey-dev	5f27923ce6	New mail in the other signed-in accounts: counts, a dot, and a notification ... With more than one account signed in (#49), mail arriving in one that isn't in front went unseen until someone switched to it (multi-account spec, MA-8). - GET /api/auth/accounts/unread answers the Inbox unread count of each account not in front, asked through that account's own session (its OAuth token renewed first if due), kept a minute per account. - The web app asks every two minutes while another account is signed in. The account menu shows each one's count beside its name, and the avatar carries a dot when any of them has unread mail. - When a count rises while the app is open and desktop notifications are on, a notification names the account ("New mail for [email protected]"); clicking it switches to that account. An account seen for the first time doesn't notify: its mail was already there. Not in this change: notifications with the app closed, which need each added account's own Web Push subscription. New strings (3, English only in the other ten catalogs): "New mail for {name}", "Unread in the Inbox: {count}", "Account: new mail in another account". Tests: the server answers the other account's count and nothing when alone; the client keeps the counts, notifies only on a rise and only with notifications on. Checked in Chrome against the mock. typecheck, tests (web 1541, server 277) and build pass.	2026-10-05 20:10:07 -07:00
jcoffey-dev	34baca4365	Account switcher: more than one account signed in at once ... Someone who looks after several mailboxes of their own can now keep them all signed in in one browser and move between them from the account menu, without signing out (multi-account spec, MA-B; forum topic 75). How it holds them. The session cookie is unchanged: it is the account in front, and every request is answered with it, so nothing else in the server changes. The others ride in a second cookie, <name>_more, as a list of their own session cookies. Each session stays its own -- sealed credential, expiry and "this is my device" -- and nothing about one is read through another. At most 5 in all, all on this mail server. - Add account (account menu): with sign-in on the mail server's page it goes there with prompt=login, so the server asks again rather than reuse the first sign-in; with the password form, a small dialog asks. Refused, and the front stays, when either account's organization has addAccounts off (inbuxa:SharingPolicy), the account is on another server, or 5 are open. The same account again just comes to the front. - Switching (POST /api/auth/accounts/<id>/front) swaps it into front; the web app clears what it cached for the previous account and reloads. A message being written blocks the switch. - Sign out ends only the account in front, and the next one comes forward; Sign out of all accounts ends every one. - GET /api/auth/accounts lists them, the front first, and says whether one more may be added. Not in this change: unread counts and notifications for the accounts not in front (MA-8), which the spec puts last. The mock can sign in a second user (MOCK_SECOND_USER/PASS) and answer addAccounts false (MOCK_NO_ADD_ACCOUNTS), for the new server tests: two accounts joining, switching, the same account twice, a switch to a session it doesn't hold, signing out of one and of all, and an organization that forbids it; and the OAuth start asking prompt=login. The client tests cover listing, switching (cache cleared, reload) and both sign-outs. Checked in Chrome against the mock: add, switch, sign out of one. New strings (9, English only in the other ten catalogs): "Add account", "Sign out of all accounts", "Add an account", "Both accounts stay signed in here; switch between them from this menu.", "Working…", "That account couldn't be added.", "You can't add more accounts here.", and the other-server and organization refusals. typecheck, tests (web 1538, server 276) and build pass.	2026-10-05 18:44:45 -07:00