Create your member account
Register, get the member group automatically, and see where that grant is recorded.
Owned by Customer (Guest) · 8 steps · about 10 minutes
Why this exists
Submitting the form creates the user, opens a session and grants the member group with the reason "self_registration" — and writes that grant to the append-only RBAC audit log with a null actor, meaning the system did it. Three grants in the platform are made that way, with no human deciding, and a null actor is how you recognise all of them: member on registration, vip_member when a VIP membership is purchased, and the Lama Family group that comes with its bundle. Everything else names the admin who decided.
What matters is that membership is the automatic one, and that is why the rest of the permission model can be strict. Because everyone who registers is a member, no other group needs a self-service path: VIP and Lama Family arrive with a purchase, host comes from an approved application, and staff groups are granted by an admin with a written reason. There is no "request access" button anywhere, on purpose.
One thing the account does not get on submit is a proven address. A verify link goes out with the redirect, and until it is clicked the account is in a soft gate (plan 39): everything works except the two actions that commit you to something — buying a ticket and applying to host. A banner on every page names the address and offers to resend. Nothing is blocked silently; the refusal says which link and where it went.
Two built details worth knowing. Registration is deliberately CSRF-exempt (there is no session to protect yet, and the form must work from a cold browser). And email uniqueness is case-insensitive and includes deactivated accounts, so a banned account's address cannot be recycled into a fresh one.
Before you start
- A logged-out browser.
- A password of at least 8 characters — shorter ones are rejected by the server, not just the form.
- An admin session for the last two steps.
Practise with
| Persona | Password | Note | |
|---|---|---|---|
| member | freya@demo.club | freya-pass-123 | a seeded self-registered member — the end state of this workflow; register a fresh address of your own to practise |
| admin | admin@club.test | admin123 | to look the new account up and read its audit trail |
Steps 1–2 — Customer (Guest)
their manual →-
1Open the registration form. Use an address nobody has used on this database.Expected result Email, password, confirm and display name.Watch out for If you are already logged in this page redirects you to your account instead. Log out first or you will think it is broken.
-
2Submit the form.Expected result A user, a signed session cookie, the member group, and a redirect to your account page.Watch out for The failures are all server-side and all specific: a password under 8 characters is refused, a mismatched confirmation is refused, and an address already in use is refused even if that account is deactivated. The form re-renders with the message rather than losing what you typed.
Steps 3 — Member
their manual →The account you just made — everything after the redirect is theirs, including the verification the first purchase waits on.
-
3Before opening your inbox, go to any event on sale and press Buy.Expected result The purchase is refused on the page you pressed it from, in a sentence naming what to do: confirm your email — the link is in your inbox, and the banner above will resend it. Nothing else about the account is restricted.Watch out for The gate applies only to accounts that were ASKED to verify — an unconsumed verify_email link. Seeded and legacy accounts predate verification and are deliberately untouched, so testing this needs an address you registered yourself. Walked by e2e/scenarios/test_wf_create_your_member_account.py.
Steps 4 — Customer (Guest)
their manual →-
4Understand the returning path too: log out and log back in from the login form.Expected result The same session cookie, and a redirect to wherever the next parameter pointed.Watch out for A wrong password gives one uniform message. The platform never tells you whether the address exists — that is deliberate, and it is why a 'no such account' message is a bug report, not a feature request.
Steps 5–6 — Member
their manual →The account you just made — everything after the redirect is theirs, including the verification the first purchase waits on.
-
5Read your own account page: your groups, the door zones those groups give you, and your active sessions.Expected result One grant — member — and the general zone.Watch out for Zones are computed from your live grants every time. They are not a field on your user row, which is why a group change moves your door access immediately.
-
6Open the member hub, which is where the platform expects you to live from now on.Expected result Your next ticket, your orders, your credit and any announcement aimed at members.Watch out for The member portal is /my and /account. There is no /portal — if a document tells you otherwise, that document predates the build.
Steps 7–8 — Admin
their manual →Confirms the automatic grant from the user record and the audit log.
-
7As an admin, open the new user and read their grant list.Expected result The member grant with the reason 'self_registration' and no granting actor.Watch out for A null actor means the system granted it. Every human-made grant on this page carries a required reason and the name of who typed it.
-
8Find the same event in the RBAC audit log.Expected result One grant row for the registration.Watch out for This table is append-only at the database level — the triggers abort an UPDATE or DELETE even from the admin data suite. Nobody can quietly rewrite who was given what.