UC-801: Administrera klasser (Class Admin)

Intent (confirmed by Paul, 2026-06-28)

Community classes are shared infrastructure: many physical objects (thin instances) point at one class for their identity — name, description, image, and later properties and relations. Because that identity is shared, someone has to own and curate it. Class Admin is that role: a place where an organisation’s members manage the classes their org owns — adding the base info and a representative image now, and properties, relations, and the wider ontology later — so that every instance pointing at a class inherits correct, consistent identity without per-object data entry.

Without this surface, classes could only be changed by direct database writes (how the first class was renamed), which is neither safe nor scalable. The forward path is the full class management console (taxonomy, properties, functional relations); this v1 is its minimal first cut (base info + image).

Summary

Allow an organisation’s members to manage their community :ObjectClass nodes — create new classes, view and edit their metadata, and set a cover image — through a dedicated web admin screen.

Actors

Actor Description
Org Member (primary) An authenticated user who is a member of at least one organisation that owns community classes
Org Admin Same role as Org Member for this use-case; no elevated permissions are needed to manage classes in v1

Preconditions

  • User is authenticated (Supabase Auth session active).
  • User belongs to at least one organisation (organization_members).
  • The organisation may own zero or more community :ObjectClass nodes.

Main flow

  1. User navigates to /admin/classes.
  2. System loads myObjectClasses — all classes owned by any org the user belongs to — and displays them in the left-hand class list (thumbnail, name, instance count, classRef).
  3. View / edit an existing class: a. User selects a class in the list. b. System displays the edit panel (name, description, cover image, read-only classRef and visibility, instance count). c. User edits name and/or description and saves → updateObjectClass → the list refreshes in place. d. User uploads a new cover image → file uploaded to Supabase Storage → setObjectClassImage called → the panel shows the new image.
  4. Create a new class: a. User presses “Ny klass”. b. System shows the NewClassDialog (name + optional description; org is the user’s active org). c. User submits → createObjectClass → the new class is added to the list and selected in the detail panel. d. User optionally sets a cover image (step 3d above).

Alternative flows

Alt When Behaviour
No classes Org exists but owns no classes List shows empty state; “Ny klass” is the primary call to action
Create with duplicate name Name already exists for another class Allowed in v1; no dedup (names are human labels — ADR-0015)
Image upload fails Supabase Storage upload error Error surfaced in the UI; class remains unchanged; no orphan concern (blob never stored)
setObjectClassImage fails after upload Storage upload succeeds but mutation call fails UI shows error; class image unchanged; storage blob is orphaned (known gap → Backlog)
Non-member attempts edit Caller is not a member of the class’s owner org Mutation returns a generic auth error; no information leak

Acceptance criteria (MVP)

  • Authenticated org members can see their org’s classes listed with thumbnail, name, instance count, and classRef.
  • An org member can create a new class (name required, description optional); it appears in the list immediately.
  • An org member can rename or change the description of a class they own; the change is reflected in the list without a full page reload.
  • Renaming a class propagates to all thin instances (which display objectClass.name when they have no own name — ADR-0058) without any per-instance write.
  • An org member can upload a cover image for a class; the edit panel shows the new image.
  • Users who are not members of a class’s owner org cannot edit or set the image for that class.
  • The screen is accessible only to authenticated users (session guard on the route).

Out of scope for this use-case

  • Hard-delete a class.
  • Editing class dependencies (SUBCLASS_OF / properties / functional relations).
  • Browsing the global public catalog of other organisations’ classes.
  • iOS “create from object” (separate flow).
  • Class image cutout/crop pipeline.
  • Flow doc: docs/flows/class-admin.md
  • Spec (history): docs/specs/2026-06-28-class-admin-web-design.md
  • ADR-0060: Community classes are organization-owned; owner lives on the canonical Neo4j class node
  • ADR-0058: Point-to-class names — display inheritance is client-side
  • ADR-0057: Neo4j canonical for class identity + relationships; Postgres images reference the class node
  • ADR-0055: cp widened to class reference — non-crypto stable id for community classes