Permissions

Chinaski has two roles for people who log in to the admin area: admin and editor, plus fine-grained limits you can put on each editor account: which content types they manage and which languages they work in. There are no other roles.

Admins and editors

Admins can do everything: user management, builds, settings, API keys, and all content regardless of restrictions below.
Editors get staff access to the admin area but can never manage users or change system settings, and their access to each content type or language can be narrowed with the two restriction fields below.

A brand-new account (created by an admin, or self-registered when self-registration is enabled) always starts as an editor. Only an admin can promote someone to admin, and a defensive guard refuses to let the last active admin demote themselves; that would lock everyone out of user management.

Scoping editors by content type

On each editor’s account page (Users → Edit) there is an Allowed content types field: a comma-separated list of content types they may manage (pages, posts, blocks, snippets, documents, categories, forms, media, navigation items, stacks, design tokens, and redirects). Leave it empty for no restriction.

How it takes effect:

Anything outside the list is unavailable to that editor: they can neither view nor mutate the gated sections, and attempting the URL sends them back to the dashboard with an error message.
Stacks are one case worth calling out: an editor without stacks in their list can’t even see the stacks lists.
Invalid or mistyped values are silently dropped when the admin saves; they don’t lock anyone out by accident.

Scoping editors by language

The Allowed languages field on the same page takes a comma-separated language code list (e.g. en, es). It works exactly the same way: empty means unrestricted, invalid values drop off silently.

If an editor edits in Spanish only:

Spanish-language view is available and access checked for creating and editing posts, pages, and other content per configured language.
Bulk operations only probe or change content for that allowed language.
JSON/CSV imports only import rows in their allowed languages; rows are scoped, not silently skipped later.

Review workflow

If Require approval (Settings → Workflow) is on, editors cannot publish directly: a publish action is converted into a submit-for-review action, the item waits in a pending status, and an admin can approve and publish it afterwards. A notification email configured under settings gets a note about the review event.

Also worth knowing while scoping people: when an account is suspended, or an admin resets someone’s password, all that user’s sessions are killed immediately, so a suspension is effective immediately, not on the next admin action.

User-management guardrails

Only admins can create, edit, or delete users.
A custom password must be at least 8 characters with at least one uppercase letter, one lowercase letter, and one digit. (The one-time setup password that replaces a fresh install’s placeholder is stricter; 12+ characters plus upper/lower/digit.)
Changing a password invalidates that user’s existing sessions immediately, so the new password takes effect on the next sign-in.

API access (outside user accounts)

Machine access uses API keys: an entirely separate Settings feature, never tied to a user account. Each key is named and created with read or write permission: explicitly write permission is required for operations that modify content, and an expired or read-only key is refused on write attempts. Optional per-key rate limiting (default 100 requests per minute, configurable in Settings) applies.

First boot

A fresh install starts with a placeholder admin password and redirects every request to /setup until a real password is set. Once set, the setup page disappears entirely.