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>
32 lines
1.4 KiB
TypeScript
32 lines
1.4 KiB
TypeScript
import type { ProvisionableUser } from 'officerdb';
|
|
|
|
// The account list the platform pushes, held for as long as this process lives.
|
|
//
|
|
// Pushed rather than fetched — see src/servers/plugins/user-provisioning.ts. It arrives once when this
|
|
// sidecar registers, and again whenever an Officer account is created or removed, so it is the current
|
|
// truth rather than a cache with an expiry: each message REPLACES what was held, never merges.
|
|
//
|
|
// In memory on purpose. Persisting it would create a second copy of the platform's own users that could
|
|
// disagree with it, and the recovery from disagreement would be re-reading the platform anyway. A restart
|
|
// re-registers, which re-sends.
|
|
|
|
let users: ProvisionableUser[] = [];
|
|
let receivedAt: Date | null = null;
|
|
|
|
export function setProvisionableUsers(next: ProvisionableUser[]): void {
|
|
users = next;
|
|
receivedAt = new Date();
|
|
console.log(`[photos] user list: ${next.length} account(s) the platform can provision`);
|
|
}
|
|
|
|
export const getProvisionableUsers = (): ProvisionableUser[] => users;
|
|
|
|
/**
|
|
* Whether the platform has told us anything yet.
|
|
*
|
|
* The distinction matters: an EMPTY list means "this server has only an owner", while never having been
|
|
* told means the plugin is not entitled or the push has not arrived. Provisioning nothing is right in the
|
|
* first case and wrong in the second, so the caller has to be able to tell them apart.
|
|
*/
|
|
export const hasProvisionableUsers = (): boolean => receivedAt !== null;
|