Skip to main content

## Module profiles

Source
Expand description

Multi-user profiles on one device.

A “profile” is an account on the currently connected Jellyfin server that this device has signed into at least once. The rows have existed since the first schema (`users`), and so have `storage_get_users` / `storage_set_active_user`; what was missing was never the storage but the decision of who may switch to what — which is domain logic, and stays here.

Two things this module is careful about:

- Switching is not logging out. `auth_logout` calls Jellyfin’s logout endpoint, which invalidates the token server-side. That is precisely the behaviour a switch must not have, or every switch back would need a password. Nothing here calls it.
- “Child account” is not modelled. A child’s profile is simply one with no PIN. The frontend receives an opaque `UnlockMethod` and renders it; it never infers a role, and no role taxonomy is invented on either side.

TRACES: UR-082, UR-083, UR-084 | DR-267, DR-268

## Modules§

pin
  Profile PIN: hashing, and the lockout policy that decides what a guess costs.
store
  Database access for profiles.
switch
  Profile switch orchestration, as a plan rather than a procedure.

## Structs§

Profile
  A switchable account on this device.

## Enums§

StartupTarget
  What the app should do when it starts.
UnlockMethod
  How a profile is entered.
UnlockOutcome
  The result of an unlock attempt.

## Functions§

startup_target
  Decide the startup target from the profiles present and the user’s setting.