Skip to content

Staff guide

Jaloliddin Ismailov edited this page Oct 4, 2026 · 7 revisions

"Staff" on the Hub does not mean "people with an admin panel". There isn't one. This guide is for the people who keep the platform honest — verifying accounts, reviewing appeals, running provisioning, answering "why can't this person do X" — using the tools that actually exist: the staff API endpoints, terminal scripts, and the database itself.

Your access is records, not a badge

Staff capability comes from authority_records like everyone else's — a platform-scoped mandate, a team participation, a body seat. There is no isAdmin flag that unlocks the world. The /api/member/team/* and /api/member/admin/* endpoints check capabilities the same way member endpoints do; see Organisation and permissions for the model. When staff access stops working, the cause is almost always a record that ended or was never granted — not a bug in the gate.

The daily workflows

Verifying and managing accounts. POST /api/member/team/membership/accounts/:id/verify confirms a registration; /status and /terminate handle the harder cases. Appeals land under /member/team/membership/appeals/:id with /review and /proof for the evidence trail.

Records. A member's authority records are visible at /api/member/admin/accounts/:id. Ending one is POST /api/member/team/membership/accounts/:id/records/:rid/end. Granting happens through provisioning scripts or the service layer — never a raw insert.

Review queues. Partnerships (/member/team/partnerships), recognition nominations, conflicts of interest, safeguarding cases and privacy requests each have a review endpoint with the same shape: list → inspect → /review or /respond with a decision. The audit trail records every transition with who made it.

Notifications. The API endpoints /api/member/admin/notifications/send, /preview and /outbox dispatch a manual notice, render a template, and show what is queued and delivered.

Terminal operations

The heavyweight work — seeding, migrations, backfills, one-off fixes — runs through the Payload local API in tsx scripts. The pattern is:

# Always against the database you intend — check twice
DATABASE_URL="postgres://localhost:5433/youngo_dev" \
  npx tsx scripts/seed.ts

Scripts in scripts/ are the maintained entry points; scripts/setup/generate-vapid-keys.mjs provisions web-push keys for a new environment. For anything bespoke, write a throwaway tsx script that calls getPayload() — you get the full typed local API with access control intact, which is strictly safer than hand-editing SQL for anything but inspection.

Reading the audit trail

/api/member/admin/audit is the system-wide transition log: who changed what, when, through which path. When a member disputes a moderation decision or a record ends unexpectedly, the audit trail is the first stop — the answer is usually there before anyone needs to touch the database.

The discipline that makes this work

Operating without an admin panel only stays safe if staff respect the same boundaries the code does: use the endpoints and scripts, let the service layer lock and validate, and treat direct SQL as a read tool. The moment a write bypasses authorityService or an endpoint's checks, the audit trail goes silent exactly where it matters most.

Clone this wiki locally