wtclaude
c29ec94f46
All checks were successful
PR checks / checks (pull_request) Successful in 1m25s
D4 asked for screenshots of the review stack rather than placeholders. Seventeen
of them: eleven of the site in a browser, six of the app on a phone, all from one
demo deployment wired to a running ServUO shard over a real sidecar, captured on
one day (D42).
The deployment is branded "Runic Gateway Demo" rather than a real community (D43),
and the captures sit beside the claims they support — the homepage, /features/, and
five of the administration pages phase 7 could describe but not show (D44).
The rig is committed rather than remembered (D45):
scripts/seedDemo.mjs content, by driving the site's own API — never SQL,
because a row the product could not have produced is
a screenshot of a product that does not exist
src/data/screens.mjs every capture: route, viewport, scroll, alt, caption
scripts/captureScreens.mjs npm run screens:capture
scripts/checkScreens.mjs the ninth check script, in CI
Shard-side dressing is servuo-plugins' scaffolding (D46), never deployed.
The rig found five things nothing else had. One is fixed upstream — a fresh
module-uo install pinned wire protocol 3 against a sidecar speaking 4, released as
v1.0.2, which this repo's own facts check then caught in platform.json. Four are
raised as product observations and worked around in the rig: a renamed guild
member never reaches the site, a guild deleted while the shard is down is a ghost
row forever, "Houses in danger" cannot show a house that was already collapsing,
and the app's news list prints raw ISO timestamps.
Players online reads 0. Logging a character in needs a UO client driven by hand,
and that is where this stopped — PLAN.md §10 says exactly why, and how to retake
the two frames that would change.
Co-Authored-By: Claude <noreply@anthropic.com>
71 lines
3.2 KiB
Plaintext
71 lines
3.2 KiB
Plaintext
---
|
|
title: Users and roles
|
|
description: The four roles and what each one reaches, creating accounts, and inviting people to a site that is not open for registration.
|
|
---
|
|
|
|
import { Aside } from '@astrojs/starlight/components';
|
|
import Screenshot from '../../../../components/Screenshot.astro';
|
|
|
|
## The four roles
|
|
|
|
| Role | Reaches |
|
|
|---|---|
|
|
| **Player** | The player portal: their own profile, their own characters and game account links, their Teams, forum access, notification preferences |
|
|
| **Moderator** | Everything a player has, plus Moderation, Appeals, Reports and the Teams admin screen |
|
|
| **Editor** | Everything a player has, plus Posts, Pages, Wiki and the Activity log |
|
|
| **Admin** | All of it, including Users, Invites, Settings, Modules, Appearance, Navigation, Authentication and the module's own admin screens |
|
|
|
|
<Aside type="note" title="Staff are players too">
|
|
Every self-service screen in the player portal is role-agnostic: it serves whoever is signed
|
|
in. An administrator has characters and Teams like anyone else, and reaches them through the
|
|
same portal. Nothing about being staff removes the player half of an account.
|
|
</Aside>
|
|
|
|
Admin routes are re-validated against the database on **every request**, not just at sign-in.
|
|
Demoting an account takes effect at once — the open session does not keep its access until
|
|
it expires.
|
|
|
|
<Screenshot id="admin-users" />
|
|
|
|
## Creating an account
|
|
|
|
**Admin → Users → + Add user** creates one directly: username, password, role, and it is
|
|
active immediately. That is the right path for staff, and for the handful of accounts you
|
|
create yourself.
|
|
|
|
The list shows each account's role, status and last login, with **View** and **Edit** on
|
|
every row.
|
|
|
|
## Invites
|
|
|
|
**Admin → Invites** is the way to let a specific person in when self-registration is off —
|
|
which is how every deployment starts.
|
|
|
|
Enter an email, pick the access level (player, moderator, editor or admin), and either
|
|
**create and email** the invitation or generate a link to share yourself. The table tracks
|
|
status, expiry and creation date, so an unaccepted invite is visible rather than forgotten.
|
|
|
|
This is worth preferring over creating accounts by hand for real people: the recipient sets
|
|
their own password, and you never handle it.
|
|
|
|
## Opening registration
|
|
|
|
When you do want a public sign-up, that is **Settings → Player registration**: password,
|
|
SSO, or both. See [Configuration](/docs/administration/configuration/).
|
|
|
|
Before opening it, know what is protecting the door: rate limiting, login backoff, a
|
|
honeypot, bot scoring and automatic IP bans — all covered in
|
|
[Authentication](/docs/administration/authentication/), along with two-factor and the SSO
|
|
policy that an external identity can only ever sign in to an account it is already linked
|
|
to.
|
|
|
|
## Status, and why deleting is the last resort
|
|
|
|
Editing an account sets its **status** as well as its role: *active*, *disabled*, *banned*
|
|
or *pending*. Disabled and banned both stop the account being used; the difference is what
|
|
you are recording — an account switched off versus an account sanctioned.
|
|
|
|
Prefer either to the **Delete** button. Content, moderation history and Team membership all
|
|
reference the account, and a disabled one keeps those records readable while a deleted one
|
|
leaves the history to explain itself.
|