Use Case: Configure Default Ownership

Updated: Sat 04 Jul 2026 — reconciled to reality: the default organisation slice is now built (iOS #180 / API #88); corrected naming and mutation names; the broader ownership strategy remains future. See ADR-0066.

Overview

Users can set a default organisation that the app opens in on login/relaunch — and that owns objects they create while it is active. This streamlines creation flows and avoids landing in the wrong org.

Built today — the “default organisation” slice (ADR-0066, iOS #180 / API #88)

The user picks a default organisation in Konto → Standardorganisation (iOS). It is the org the app opens in on cold-start/login, stored server-side so it follows the user across devices and survives sign-out.

  • Backend: profiles.default_organization_id (nullable uuid, FK organizations(id) ON DELETE SET NULL). Read via myProfile { defaultOrganizationId }; set via setDefaultOrganization(organizationId): Profile! (membership-gated in the resolver — you must be a member of the org).
  • Cold-start resolution (client, ActiveOrgResolver): cachedDefault (if still a member) ?? serverDefault (if a member) ?? own personal org (isIndividual && role == "owner") ?? first. The role-based personal-org fallback fixes the old bug of landing in a stranger’s individual org.
  • Local-first: the default is cached and applied instantly/offline; setting it is optimistic + write-behind (server = durability only).
  • Distinct from the navigator’s transient “Skapar som” switcher, which changes the working org for the current session only; on restart the active org re-seeds from the default.

Flow doc (living): Plings-iOS/docs/flows/default-organization.md.

Not yet built — the broader ownership strategy (future)

The original design envisioned a full three-way default ownership strategy for newly created objects, which is not implemented:

  1. Me – the user’s personal account.
  2. Organisation – any organisation the user belongs to (this is the slice built above).
  3. Container’s Owner (Default) – inherit ownership from the container where the object is placed.

That would add a profiles.default_ownership enum (strategy) alongside default_organization_id, a Settings UI with the three radio options, and an updateUserSettings-style mutation. Today, new-object ownership simply follows the active organisation. The “Container’s Owner” inheritance option in particular is future work — track it in the owning repo’s ROADMAP Backlog when picked up.