Demo data

Development data to try the app as different people: a platform admin, organization admins, a unit admin and plain members, in organizations with units and todos. There are two sets: the seed every quickstart runs, and a larger demo set for walking through units and roles. Both refuse production and non-local databases, and re-running them is safe.

The seed (keelmint-db:seed)

pnpm nx run keelmint-db:seed

Every password is keelmint-dev-password (set SEED_PASSWORD to use another; a non-local database needs SEED_ALLOW_REMOTE=true and an explicit SEED_PASSWORD). admin@keelmint.local is the platform admin and belongs to no organization.

Organization (slug)	Units
Acme Accounting (acme-accounting)	London, Manchester (sub-unit: Payroll)
Globex Partners (globex-partners)	-

Email	Acme Accounting	Globex Partners
alice@keelmint.local	ORG_ADMIN, USER (whole organization)	USER
bob@keelmint.local	USER (whole organization); UNIT_ADMIN of Manchester	-

Roles are organization-wide unless a unit is named: bob is a unit admin, managing Manchester and its sub-unit Payroll, not the rest of Acme Accounting. USER carries Keelmint’s own-todo permissions. Each membership has its own todos, so switching organizations visibly changes the list. The seed’s organizations have the Business plan set by hand, so plan limits stay out of the way.

A generated single-mode product has no seed organizations: its seed puts alice and bob in the built-in default organization. After prisma migrate reset, run the seed again.

The demo organizations (keelmint-db:seed-demo)

Two more organizations with deeper unit trees, to try members, units and todo visibility. Create or refresh them:

pnpm nx run keelmint-db:seed-demo

Every password is the account’s email. Login is rate limited to 5 attempts a minute per IP: wait a minute when you see “Too many requests”.

Demo Accounting (demo)

Demo Accounting
├─ London (branch)
│   ├─ Accounting (department)
│   └─ Payroll (department)
└─ Manchester (branch)
    └─ Sales (department)

Email (= password)	Roles	Their todos	Should see
orgadmin@demo.local	ORG_ADMIN, USER, TODO_SUPERVISOR (org-wide)	2	All todos: 13, and may edit and delete any of them. Members: 7. Settings; the audit log and helpdesk of the whole organization.
london.manager@demo.local	UNIT_ADMIN @ London, TODO_SUPERVISOR @ London, USER	2	All todos: 7 (own, mary’s, nick’s), may edit and delete them. Members: 3. Tree starts at London. Users, audit log and helpdesk: those 3 people.
manchester.manager@demo.local	UNIT_ADMIN @ Manchester, TODO_SUPERVISOR @ Manchester, USER	1	All todos: 4 (own, chris’s, sophie’s), may edit and delete them. Members: 3.
mary@demo.local	USER @ Accounting, USER	3	Own todos only; All todos and Members: 403.
nick@demo.local	USER @ Payroll, Senior accountant @ London, USER	2	All todos: 7 and Members: 3 (London), through the organization role; read only (no Todos.UpdateAny/DeleteAny).
chris@demo.local	USER @ Sales, USER	2	Own todos only.
sophie@demo.local	USER @ Manchester, USER	1	Own todos only.

A todo has no unit: an admin reaches it through its owner’s units. A member is in the units they hold a role in, so london.manager reaches the members of London, Accounting and Payroll (mary, nick), not those of Manchester.

Demo Accounting Scotland (demo-scotland)

Demo Accounting Scotland
├─ Edinburgh (branch)
│   └─ Edinburgh Accounting (department)
└─ Glasgow (branch)

Email (= password)	Roles	Their todos	Should see
mary@demo.local	ORG_ADMIN, USER, TODO_SUPERVISOR (org-wide)	2	All todos: 5, and may edit and delete them. Members: 3.
peter@demo.local	USER @ Edinburgh Accounting, USER	2	Own todos only.
anna@demo.local	USER @ Glasgow, Front desk, USER	1	Own todos; Members: 3 (organization role).

mary is in both. She logs in to Demo Accounting, where she is a plain member; the header switcher takes her to Demo Accounting Scotland, where she is the administrator. Each organization shows only its own todos and members.

Roles the demo uses

System roles are the same in every organization and managed by the platform admin on /admin/roles (their initial permissions come from libs/keelmint/shared/src/product.config.ts). Organization roles belong to one organization and are edited on its Roles tab; the demo creates TODO_SUPERVISOR as one in each demo organization.

Role	Kind	Permissions	Why
USER	system (the default)	Todos.Read, ReadOne, Create, Update, Delete	Own todos; in a unit it also links a member to it.
ORG_ADMIN	system	members, invitations, units, organization, audit, roles, helpdesk, todos (incl. ReadAny, UpdateAny, DeleteAny)	Organization-wide: every member’s todos.
UNIT_ADMIN	system	ORG_ADMIN’s minus billing, settings and role writes	Held in a unit: that unit and below, and their members’ todos.
TODO_SUPERVISOR	organization (each demo)	Todos.ReadAny	Read everyone’s todos in reach (the admins already hold it through their system role).
Senior accountant	organization (demo)	Members.Read, Todos.ReadAny	nick, at London: reads that branch’s members and todos.
Front desk	organization (demo-scotland)	Members.Read	anna, org-wide: the member list, not others’ todos.

Nobody grants more than they hold: london.manager may give TODO_SUPERVISOR or Senior accountant at London (and below), where the role holds those permissions, but not organization-wide or at Manchester (403 “You cannot grant permissions you do not have”); manchester.manager cannot give Senior accountant anywhere outside Manchester.