pastilhasandClaude Fable 5
a83da42a1f
Photos had no user provisioning at all: one registry row, the owner's, and every other account resolving to nothing. Same shape as the Jellyfin gap, but this one was never built rather than built and dropped. photos_accounts records who on Officer is who on Immich, and carries that person's own API key. getConfig falls back to it when the caller has no registry of their own, and there is no path from there to the owner's key — an Immich key with permissions:['all'] can read and delete the whole library, so a member resolving to it would be administering everyone's photographs rather than reading their own. Matching is on email, which Immich enforces uniqueness on and Officer already holds. That is exact where the Jellyfin side has to go through an uppercased username index and cope with two Officer names colliding into one. Two deliberate differences from the Jellyfin flow: The admin's own account is reported as itself, not as "no Officer account". That bug shipped there and was fixed in 591c0da; there was no reason to write it twice, so reconcile takes the key's identity from /api/users/me and the test pins it. And the temporary password is HANDED OVER rather than discarded. Jellyfin discards because it has no must-change-password flag, so anything handed over stays valid forever. Immich has one, and Immich's own app is where phone backup runs — discarding would leave a photo account that can never back a phone up again. So: set a password, spend it on a key, raise shouldChangePassword, return it once. POST /_config/:id/handover re-issues on demand, because "setting up my phone" happens long after provisioning and more than once. Verified against the running 3.1.0 image that an API key survives a password change, so re-issuing never costs Officer its access. Applied on alpha: conceiba and fedra linked, guipinto and diogo created, all four keyed and each resolving to their own Immich identity. jrg.conceicao left alone. Members still need the photos grant on the Member role before the permission gate lets them through. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Photos
Your Immich library, reached through Officer.
Photos does not store photographs and does not install Immich. You point it at an instance you already run; it forwards to it and holds the API key server-side, so no device ever carries one. Your library, your originals and every thumbnail stay exactly where they are.
What you get
- The whole library — timeline, albums, people, places, sharing and search, as panels inside Officer.
- A map of everything with coordinates, clustered.
- Upload from the phone, through Officer rather than to Immich directly.
- More than one instance. Accounts are a per-user registry with a label, a URL and a key; one is active and you switch between them in the app.
What you need
An Immich you already run, and an API key from it (Immich → Account Settings → API Keys).
Create the key with all permissions. A scoped key returns 403 per route, which does not read as a permissions problem — it reads as a broken feature, one screen at a time.
Nothing else. No system packages, no host binaries.
Setup
- Install the plugin.
- Open /photos → Connection and add an instance: a label, its URL, and the API key.
- It probes the server, records its version, and marks the account active.
What it deliberately does not do yet
- It is a client, not a backup. Nothing is copied to Officer. If your Immich goes away, so does the library — this plugin never held it.
- The key is write-only across the boundary. The account list reports label, URL and which is active, and has no field that could carry a key, masked or otherwise. The only way to change one is to replace it. That is deliberate, and it means the app cannot show you a key you have forgotten.
- Editing lives in Immich. This browses, searches, uploads and organises into albums; it is not a photo editor and will not become one.