@startinblox/tamis-onboarding

TAMIS onboarding administration UI — operator dashboard and review flow, delivered as Lit web components on top of the Startin'blox SOLID framework (sibStore, sibRouter, Orbit).

Replaces the Django server-rendered registration-admin/ templates that ship inside djangoldp_tamis_onboarding — the Django views remain for the public registration form and attachment downloads, but operators use these components.

Components

| Element | Role | |---|---| | <solid-tamis-onboarding> | Top-level OrbitComponent. Point data-src at the RegisterParticipant LDP container; the component watches sibRouter and either renders the list or the review view. | | <tamis-onboarding-participants-list> | Sortable dashboard table — submitted / organisation / requester / types / status badge / actions. Approve and Deny buttons request navigation to the review route. | | <tamis-onboarding-participant-review> | Full-detail review card — organisation, legal address, main contact, billing contact, attachments, lifecycle — plus the confirm form (notes textarea appears on deny). |

State mutations go through window.sibStore.patch(...):

• Approve — PATCH { status: "processing" } on the participant. The djangoldp_tamis_onboarding background task promotes processing → approved after Keycloak provisioning.
• Deny — PATCH { status: "rejected", notes: "…" } on the participant. Rejection requires operator notes (server-side validation in models.py).

Access control is server-side: the LDP RegisterParticipant.permission_classes gate writes to authenticated operators.

Usage in Orbit

<script type="module" src="https://cdn.jsdelivr.net/npm/@startinblox/core@latest/dist/index.js" defer></script>
<script type="module" src="https://cdn.jsdelivr.net/npm/@startinblox/tamis-onboarding@latest" defer></script>

<solid-tamis-onboarding
  data-src="https://onboarding.tamis.example.com/onboarding/registerparticipants/"
></solid-tamis-onboarding>

Attachments are downloaded via the existing Django view (/registration/admin/attachments/<pk>/) — the download_url field on each attachment resource points at it. The endpoint gates on operator membership.

Requirements on the backend

The LDP resource must expose attachments as a nested field, and each ParticipantAttachment must serialize @id, kind, kind_display, original_filename, mime_detected, size_bytes, download_url, uploaded_at. This is on djangoldp_tamis_onboarding ≥ the version that added nested_fields = ["attachments"] to RegisterParticipant.Meta.

Development

npm install
npm run storybook   # isolated component dev at http://localhost:6006
npm run build       # produces dist/index.js (ESM, target esnext)
npm run cy:run      # cypress component tests

See AGENTS.md for the boilerplate conventions this repo is built on (component base classes, cherryPickedProperties, gatekeeper(), i18n patterns).

License

MIT.