pastilhas
470d4f83c3
the platform pushes the account list (users:list, declared by userProvisioning in the manifest); this decides what to do about each one and does it. DECIDING IS SEPARATE FROM DOING. reconcile.ts is pure and has no idea what jellyfin is — which is why it can be tested against the real populations on alpha without creating anything. nine tests, built on the actual overlap: diogo and fedra already have jellyfin accounts, conceiba and guipinto do not, rezio and peter exist only on jellyfin. that test found a real bug before it shipped. officer's `username` was unique CASE-SENSITIVELY, so `diogo` and `DIOGO` could both exist here while colliding on jellyfin's uppercased NormalizedUsername index — and the first version handed both the same jellyfin account, because it only checked links that already existed rather than ones claimed during the pass. the platform side is now case-insensitive too, so the collision cannot be created in the first place; the guard stays because the constraint and the guard protect different moments. three outcomes, and the third is the point: LINK an account that already exists, CREATE one that does not, LEAVE ALONE a jellyfin account with no officer user. never delete. an absence in officer is indistinguishable from a list that has not been told about someone yet, and a wrong deletion costs somebody their watch history. `adopted` carries that distinction into the mapping table. false means officer made the account and may remove it; true means it existed first and was merely linked. NOBODY IS EVER TOLD THEIR PASSWORD. jellyfin has no must-change flag — verified against its openapi, UserPolicy has 44 properties and none of them is one — so a handed-over password stays valid forever. instead the generated one is used once, immediately, to mint that person's own access token, and discarded. the account exists and their officer session can already read their library. which also makes rule 4 unskippable: the sign-in that verifies the account is the same call that obtains the token, so there is no version of this that "verifies later". one failure does not stop the rest. a partially provisioned server is fixed by running again; a run that aborts on the first error leaves everyone after them unprovisioned and no record of who.
56 lines
2.2 KiB
TypeScript
56 lines
2.2 KiB
TypeScript
import type { PluginManifest } from '@@/plugins/manifest';
|
|
|
|
/**
|
|
* Jellyfin — films and shows from your own server, with a player that handles direct, HLS and
|
|
* progressive playback.
|
|
*
|
|
* ── What this plugin is, and what it is not ──
|
|
*
|
|
* It does not install or supervise Jellyfin, and it stores no media. You point it at a server and it
|
|
* speaks Jellyfin's API on your behalf, holding the access token server-side so no device carries it.
|
|
*
|
|
* ── Where the connection lives ──
|
|
*
|
|
* In this plugin's OWN table, unlike transmission and soulseek. `jellyfin_servers` is a registry — label,
|
|
* URL, encrypted token, one active — because more than one Jellyfin really is a thing someone has (a
|
|
* home server and a friend's, say). That is the same reason `photos_config` is plural and
|
|
* `service_connections` is not.
|
|
*
|
|
* ── The vendored player ──
|
|
*
|
|
* `web/vendor/hls.mjs` is a checked-in third-party build, ~1.3 MB. It is deliberately excluded from
|
|
* formatting and lint: reformatting it would destroy the diff against upstream, which is the only thing
|
|
* that makes a vendored library reviewable. See the README beside it.
|
|
*
|
|
* ── No `osDependencies` ──
|
|
*
|
|
* Nothing shells out. The sidecar speaks Jellyfin's HTTP API over `fetch`, and transcoding is the
|
|
* server's job, not ours.
|
|
*/
|
|
export const manifest: PluginManifest = {
|
|
publisher: 'officerdev',
|
|
version: '1.0.0',
|
|
platform: '>=1.0.0',
|
|
|
|
label: 'Video',
|
|
summary: 'Films and shows, with a player that handles direct, HLS and progressive',
|
|
icon: 'Clapperboard',
|
|
color: '#a855f7',
|
|
|
|
// Jellyfin accounts are created one per Officer account. Declared here so the owner sees it on the
|
|
// install screen beside the permissions — "this plugin will be told who your users are" belongs where a
|
|
// person decides, not in a log afterwards.
|
|
//
|
|
// What it turns on: the sidecar receives `users:list` when it registers and whenever an account is
|
|
// created or removed. See src/servers/plugins/user-provisioning.ts and plugins/USER_PROVISIONING.md.
|
|
userProvisioning: true,
|
|
|
|
permissions: [
|
|
{
|
|
key: 'jellyfin',
|
|
label: 'Video',
|
|
description: 'Browse and play the Jellyfin library',
|
|
},
|
|
],
|
|
};
|