RFC: Custom roles and collection-scoped permissions

[danielmlr]

Summary

This RFC proposes custom roles: a site defines its own roles from the existing permissions and can limit a role's content permissions to chosen collections. It develops #824, which asks for "user A can edit posts in collection X but not Y" and proposes a tuple-based model. It also replaces the per-collection min_role I suggested in a comment there. The five built-in roles, their levels and every permission name stay as they are. On a site that defines no custom role, the built-in roles hold the permissions they hold in EmDash 1.0 and no request issues an additional query.

The work has three phases:

1. One authorization path. Every role check in REST, MCP and plugin routes goes through the permission map, and the admin receives the signed-in user's effective permissions instead of deriving them from the role number. This phase changes no data model, is useful without the other two, and addresses several open reports.
2. Roles as data. A roles table, collection scope for content permissions, and an API, a CLI command and a seed format for roles.
3. Role editor. A permission matrix in the admin.

Public member accounts, multi-tenancy, field-level permissions, plugin-defined permissions and approval workflows are out of scope.

Example

Every name and shape in this section is illustrative.

A site has posts, pages and jobs collections. One person maintains the job postings and should edit and publish entries in jobs and nothing else. The seed file declares a role for that person:

{
	"roles": [
		{
			"slug": "jobs-editor",
			"label": "Jobs editor",
			"permissions": ["media:read", "media:upload", "taxonomies:read"],
			"collections": {
				"jobs": [
					"content:read",
					"content:read_drafts",
					"content:create",
					"content:edit_any",
					"content:delete_any",
					"content:publish_any"
				]
			}
		}
	]
}

A user with this role gets these results:

Request	Result
POST /_emdash/api/content/jobs	201
POST /_emdash/api/content/jobs/{id}/publish	200
GET /_emdash/api/content/posts	403
PUT /_emdash/api/content/posts/{id}	403
MCP content_update with collection: "posts"	refused
POST /_emdash/api/menus	403

The admin sidebar lists Jobs as the only collection for this user.

The admin learns what to show from GET /_emdash/api/auth/me. In EmDash 1.0 that person would be an Editor, and the endpoint returns the role number:

{
	"id": "01JZ3W9Q0V5T8K2M4N6P7R8S9T",
	"email": "sam@example.com",
	"name": "Sam",
	"role": 40,
	"avatarUrl": null,
	"isFirstLogin": false
}

With the jobs-editor role the response also carries the effective permissions:

{
	"id": "01JZ3W9Q0V5T8K2M4N6P7R8S9T",
	"email": "sam@example.com",
	"name": "Sam",
	"role": 10,
	"roleSlug": "jobs-editor",
	"permissions": ["media:read", "media:upload", "taxonomies:read"],
	"collections": {
		"jobs": [
			"content:read",
			"content:read_drafts",
			"content:create",
			"content:edit_own",
			"content:edit_any",
			"content:delete_own",
			"content:delete_any",
			"content:publish_own",
			"content:publish_any"
		]
	},
	"avatarUrl": null,
	"isFirstLogin": false
}

role stays in the response and holds the compatibility level described under Compatibility level in the Detailed Design.

On the server, the content update route in EmDash 1.0 checks ownership and permission:

const editDenied = requireOwnerPerm(user, authorId, "content:edit_own", "content:edit_any");

With this RFC the same helper also receives the collection:

const editDenied = requireOwnerPerm(user, authorId, "content:edit_own", "content:edit_any", {
	collection,
});

#2332 asks for a role equal to Subscriber plus editing byline information. As a custom role, that is the Subscriber permissions and one more:

{
	"slug": "byline-editor",
	"label": "Byline editor",
	"permissions": [
		"content:read",
		"media:read",
		"taxonomies:read",
		"comments:read",
		"menus:read",
		"bylines:read",
		"widgets:read",
		"sections:read",
		"search:read",
		"auth:manage_own_credentials",
		"bylines:manage"
	]
}

Background & Motivation

Four places compare the role number instead of using the permission map

packages/auth/src/rbac.ts maps 50 permission names to a minimum role level, and the check is user.role >= Permissions[permission]. AGENTS.md states that authorization is permission-based and that this map is authoritative. Most REST routes follow that rule, but four areas do not:

• User management. The routes for users, invites, allowed signup domains, API tokens and OAuth clients compare the caller's role to Role.ADMIN directly, 19 checks in 12 route files. Eight permissions in the map are never checked by core, users:read, users:invite and users:manage among them.
• MCP. The MCP server calls requireRole with a role level at 53 call sites, beside the permission names that the matching REST routes use. The two can drift apart, and fix(core): require edit permission on the source for the MCP content_duplicate tool #3433 fixed one such case in content_duplicate.
• Visual editing. The middleware that enables edit mode on site pages compares user.role >= 30, and the client toolbar script makes the same comparison on the role number from /auth/me.
• Admin. GET /_emdash/api/auth/me returns the role number and no permissions, and the admin package does not depend on @emdash-cms/auth. Instead, it declares 25 numeric role constants in 13 files and decides what to show by comparing against them.

Several open reports follow from the admin and the server deciding separately:

• Bug Report + UX: Subscriber role has excessive admin access + login page needs overhaul #1132: a Subscriber sees the collections and plugin pages in the sidebar, the settings pages and delete buttons, and the API then rejects the actions.
• RBAC / Content Editor - Non-entitled users need more messaging / UX around "your role doesn't allow you to see this" #2221: opening an entry that the role may not read shows a blank screen.
• Let a plugin admin page declare a minimum role, so the sidebar hides it from roles that cannot open it #3034 and plugin-forms: all routes default to plugins:manage, so an Editor gets 403 and the admin shows "No forms yet" instead of a permission error #3033: plugin pages are listed for every role, while a plugin route without a permission requires plugins:manage.

The Contributor role shows the same split. On a 1.0.1 site a Contributor creates an entry (201) and is refused on the next save (403), while the editor shows Save, Publish now and Schedule. The map grants content:create from Contributor and content:edit_own from Author. The authentication guide describes the role as "Create content (needs approval to publish)".

What a ladder of five levels cannot express

Each level holds every permission of the levels below it, and every content permission applies to every collection. Two kinds of request fall outside that:

• A permission without the rest of its level. [Roles] Add subscriber + byline editor only role (or allow custom roles) #2332 asks for a Subscriber who can also edit byline information, and names custom roles as one way to get there.
• A permission for some collections only. Pluggable authorization layer — user RBAC is too coarse for multi-tenant/delegation scenarios #824 asks for users who can edit one collection and not another. Feature Request: Declarative Admin Sidebar Navigation (Grouping & Role Guards) #2317 describes a site with more than twenty collections and a role for external users, and patches the sidebar to simplify the view for that role.

For the person in the Example who should edit only the job postings, the built-in roles alone offer two answers: a role that can edit every collection, or a second site.

#2358 reports the same limit for tokens: a token that can load the admin needs the admin scope, and no step exists between read scopes and full access.

What any change has to keep

The role integer and the permission names are public surface in 1.x:

• The integer appears as locals.user.role, as ctx.user.role in plugin routes, as actor.role in content hooks, in the role options of the Cloudflare Access and Atmosphere providers (roleMapping, defaultRole), and as minRole on plugin editor panels and list columns.
• toRoleLevel throws on any value other than the five levels, and the auth adapter calls it for every user row it loads. A deployed version cannot load a user whose role column holds a sixth value.
• Plugin routes and plugin MCP tools name a permission from the map. A route that names anything else answers 500.

So the design only adds: it renames, renumbers and removes nothing.

Goals

• A site can define a role that holds a chosen subset of the existing permissions.
• A role can hold content permissions for chosen collections and is refused in all others, identically through REST, MCP and the admin.
• The admin decides what to show from the permissions the server sent. It holds no role thresholds of its own.
• REST and MCP evaluate the same permission for the same operation.
• A request from an anonymous visitor loads no role and issues no additional query. A request from a user with a built-in role issues no additional query. A request from a user with a custom role issues no additional round trip.
• The five built-in roles hold exactly the permissions they hold in EmDash 1.0.
• Installed plugins, issued tokens and configured identity-provider mappings keep working unchanged.
• Every schema change is additive, and a version deployed before the change keeps working against the expanded schema.

Non-Goals

• Public member accounts. Reader, commenter and paying-subscriber accounts, open signup and paywalls belong to Feature Request: "Public Membership" Mode (Open Registration, Custom Login UI, and Role-Based Routing) #590, Feature request: open signup + public subscriber profiles #1315 and Exploring Native Paywall Support in EmDash Core #1467. Those threads weigh an account type separate from users. This RFC covers the people who work in the admin.
• Multi-tenancy and organizations. Site isolation and organization-scoped content belong to Feature Request: Multi-tenancy through dynamic bindings #139 and Expose a Kysely-plugin pass-through on the DB config for row-level content scoping (multi-tenant / orgs) #3079.
• Field-level permissions. The Security Model section explains why.
• Row-level rules beyond own and any. No filter language and no policy documents.
• Plugin-defined permissions. Core owns the set of permission names. A plugin route keeps naming a core permission (RFC: Let plugins explicitly declare MCP tools #1587).
• Approval workflows. No review state and no multi-step workflow. A role without a publish permission cannot publish, which the existing permissions already express.
• Changing the built-in roles. They cannot be edited or removed, and no permission is renamed.
• Deny rules. Roles only grant.

Prior Art

Content management systems follow four approaches to authorization:

Approach	Used by	Properties
Fixed role list	EmDash 1.0	One comparison in memory. The set of roles changes only with a release.
Permission sets stored as data	WordPress, Drupal, Craft	A role is a stored set of permission names. A check reads the set.
Access functions in code	Payload, Keystone	A function decides each operation and can return a query constraint. The rules live in site code.
Policies with filters, stored as data	Directus	Additive policies carry item rules that are combined across policies. The model needs a filter language.

EmDash keeps its schema in the database and runs plugins in a sandbox, so the second approach fits: a role is data, and a check reads a set. Drupal and Craft generate permission names per content type or section (edit any $type_id content in NodePermissions.php, saveEntries:<section uid> in UserPermissions.php). This RFC reaches the same granularity with a collection scope on a grant, so the permission names that plugins already reference stay as they are.

Field-level read restrictions have a recurring failure: a restricted field leaks through filtering, sorting or relation traversal. Strapi GHSA-rjg2-95x7-8qmx (CVE-2026-27886) and Payload GHSA-9g87-32v6-3c2r and GHSA-fpww-c55p-cjv6 are instances. In Directus GHSA-97xr-jchp-xm3c, clients gained unrestricted item access after a failed authentication message. The check in this RFC denies whenever there is no actor.

When Ghost needed a role that cannot publish, it added Contributor and left Author unchanged for backwards compatibility (TryGhost/Ghost#9314). The same rule applies here: no built-in role is narrowed.

Detailed Design

This section describes the design at interface level. Field-by-field definitions belong in the RFC document that follows an accepted Discussion.

Vocabulary

Term	Meaning
Permission	A name from the map in rbac.ts, such as content:edit_own. Core owns the set. Existing names do not change, and new names are additions.
Grant	A permission held by a role. A grant of a content:* permission applies to all collections or to a list of collection slugs.
Role	A named set of grants. The five built-in roles are defined by the map. A custom role is a stored row.
Actor	The signed-in user together with the grants of the user's role. A check receives an actor.

Check

One function decides, sketched as can(actor, permission, resource?), where resource carries an optional collection and an optional ownerId. hasPermission, requirePerm, requireOwnerPerm and requireAnyPerm stay and call it.

• A missing actor is a denial.
• For a built-in role the answer comes from the map, unchanged.
• For a custom role the answer comes from its grants.
• A grant scoped to collections satisfies a check only when the resource names one of those collections. A check that names no collection is satisfied only by an unscoped grant.
• A grant of an _any permission includes the matching _own permission. The built-in ladder guarantees this. A custom role is a free set, and canActOnOwn asks for the _own permission when the actor owns the item, so the check adds _own wherever _any is granted.
• Ownership keeps its rules, including the rule that an empty owner id matches nobody.
• An unknown role reference yields no grants. An unknown permission name in a stored role is ignored.

Roles and storage

A custom role is a row in a new system table. Users, invites and allowed signup domains gain a nullable reference to it.

Field	Purpose
id, slug, label, description	Identity. The slug is unique and is the name that seed files and provider mappings use.
grants	The permission names the role holds, with the collection scope of its content permissions.
users.role_id	The user's custom role. NULL means the built-in role in users.role, which is the state of every existing user.
users.role	Stays. For a user with a custom role it holds the compatibility level.

A user has one role. Someone who needs what two roles grant gets a third role that combines them.

Anonymous requests load no user and therefore no role. Built-in roles resolve from the map in memory. The row of a custom role has to arrive without an extra round trip, and Unresolved Questions names two ways to do that.

Compatibility level

Code that reads the integer keeps working: third-party plugins, minRole on plugin panels, and a version deployed before the migration. For a user with a custom role, users.role holds the highest built-in level whose permissions the custom role fully contains for all collections. A custom role that contains no built-in role is stored as Subscriber, the lowest of the five levels.

Custom role	Compatibility level
Editor permissions without menus:manage	30 (Author)
byline-editor from the example	10 (Subscriber)
jobs-editor from the example	10 (Subscriber)

Code that reads only the integer therefore never grants more than the role holds, with one exception. A role narrower than Subscriber, such as jobs-editor, appears to that code as a Subscriber, which can read published content in every collection.

Effective permissions in the admin

/auth/me returns the actor's unscoped permissions and its per-collection permissions, as in the example. The admin gets one hook, sketched as useCan(permission, resource?), which replaces the numeric comparisons in the sidebar, the command palette, page-level checks and action buttons. The server stays the security boundary; the payload only keeps the admin from offering what the server will refuse.

Content routes, lists and MCP

Content routes run their check in the route file, where the collection is already a URL parameter, so the check takes it from there. The revision routes and bulk tagging have no collection in the URL and take it from the loaded revision or from each item.

Collection scope needs no row filter. A list request for a collection that the role may not read is refused. Reads that cross collections, such as search, the calendar and the relation routes, apply the scope to each collection they touch.

MCP tools call the same check with the same permission names as their REST counterparts and pass the tool's collection argument. requireRole goes away. Where a tool's role level differs from the REST permission in EmDash 1.0, phase 1 settles each difference on its own, with the REST permission as the default. media_create is one: the tool asks for Author, a level that the AI tools guide and the MCP server reference document, and the REST route that confirms the same upload asks for media:upload, which a Contributor holds.

Plugins

Nothing changes in the plugin contract. A route names a core permission and defaults to plugins:manage. The dispatcher passes the actor, so a custom role that holds the named permission can call the route. ctx.user.role and actor.role carry the compatibility level.

Plugin pages become visible by permission. A Block Kit page loads through the plugin's admin route, so the admin can show the page when the actor holds that route's permission. #3034 raised the problem and weighs an explicit field on the page against deriving visibility from the route. A role level says nothing about a custom role, so either choice has to be stated as a permission name.

Tokens

The rule stays: effective access is the token's scopes intersected with the role's permissions. scopesForRole derives the allowed scopes from the actor's grants and no longer from a minimum level, and has to yield the same result for built-in roles. Clamping at issuance and at refresh stays.

Identity providers

roleMapping and defaultRole in the Cloudflare Access configuration and defaultRole in the Atmosphere configuration accept a role slug in addition to a number.

Managing roles

• API. Routes under /_emdash/api/admin/roles list, create, update and delete custom roles.
• CLI. A command, sketched as emdash role, lists, creates, updates and deletes custom roles. Like emdash menu and emdash taxonomy, it goes through the REST API.
• Seed. The seed file gains a roles section, so a site can keep its roles in version control. emdash export-seed writes it.
• Who may manage. Only the built-in Admin role manages roles and assigns them. A custom role cannot hold users:read, users:invite or users:manage.
• Last admin. The existing guard counts enabled users with the built-in Admin role and stays as it is.
• Deleting. A role that is assigned to a user, an invite or a signup domain cannot be deleted.

Security Model

• Fail closed. No actor, an unknown role reference, an unknown permission name and a content check without a collection against a scoped grant all deny.
• Privilege escalation. Only built-in Admins create, change and assign roles, and custom roles cannot hold the user-management permissions. Whether another Admin-level permission opens an indirect path is listed under Unresolved Questions.
• Older code. A version that does not know custom roles reads users.role. With the compatibility level it grants at most the built-in role the custom role contains, or Subscriber. This covers a rolling deploy and a rollback.
• No field-level permissions. The advisories under Prior Art show that a field restriction has to hold in filtering, sorting and relation traversal as well as in the response body. A collection scope is coarser: it is decided once per request and collection. Reads that cross collections still have to apply it, which the testing strategy covers.
• Kept invariants. Users without content:read_drafts keep receiving 404 for unpublished entries. The empty-owner rule, the last-admin guard, the ban on changing one's own role and scope clamping at token refresh stay.
• When role changes take effect. The user row is loaded for each authenticated request, so a reassigned role applies on the next request. An edited role applies when the role row is next read fresh: on the next request with the join named under Unresolved Questions, and with the object cache once the invalidation reaches the isolate, which with Workers KV takes up to about a minute.

Testing Strategy

• Equivalence. For each built-in role and each permission, the new check returns what role >= Permissions[permission] returns. This pins the check itself to the current map for the built-in roles.
• Scope. Route tests with a collection-scoped role cover the content routes, including the routes without a collection in the URL, search, the calendar, and relations that point into a collection the role may not read.
• Parity. One table of operations drives REST and MCP tests, so both surfaces are asserted against the same expected permission.
• Query counts. The query-count snapshots for anonymous routes do not change. A test asserts the round trips of an authenticated content request with a built-in role and with a custom role.
• Migration. Upgrade from existing data, retry after a partial run, and every supported dialect.
• Compatibility level. Derivation tests, and a test that code reading only users.role never grants more than the custom role, apart from the Subscriber floor.

Drawbacks

• New core permissions do not reach custom roles. A built-in role receives a new permission through the map. A custom role holds what it was given, so an upgrade can leave a custom role without access to a new feature until an Admin grants it.
• Roles are no longer totally ordered. Code and documentation that compare levels ("at least Editor") have no meaning for a custom role. The compatibility level is a conservative answer, apart from the Subscriber floor, and hides plugin panels with a minRole from custom roles that hold the underlying permissions.
• A larger test surface. Each content route needs a scoped case, and the role editor needs the care any admin screen needs, including right-to-left layouts.

Alternatives

One minimum role per collection

I proposed this in a comment on #824: a nullable min_role on the collection, checked next to the permission. It needs one column and no new concept, but it is one-dimensional. It can raise a collection above a level, which separates one group from the rest. Whoever reaches the higher threshold also passes the lower one, though, so it cannot express two departments that must not edit each other's collections. It does not cover #2332 either. This RFC replaces that proposal.

Built-in role plus a collection list

A user keeps a built-in level and gains a list of collections. This keeps the order total and is smaller than roles as data. However, it covers the collection cases and not #2332, and the first request for "Editor without one permission" would need a second migration.

Generated permission names per collection

Generated names such as edit any article content would work as they do in Drupal and Craft. In EmDash, however, the permission names are a closed type that installed plugins reference, so generated names would change a public contract. A scope on the grant reaches the same result.

Access functions in site code

Payload and Keystone let site code decide each operation. EmDash collections are created at runtime in the admin, and roles need to be managed there too. Rules written in site code cannot be managed from the admin.

Veto hooks in a site plugin

content:beforeSave and content:beforePublish receive the actor and the collection, so a site plugin can already refuse saves and publications per user and collection. That covers writes only. Lists, reads and the admin still show every collection to the role, and deletion, restore and discarding a draft run no hook that both knows the actor and can refuse. The rule also lives in plugin code, outside the roles an Admin manages.

Policies with filters, and relationship tuples

Filter-based policies and the tuple model that #824 opens with can express row-level and delegated access. Both decide per row, so every query that reads content has to carry their constraint. The custom-role and collection requests under Background do not need that. The delegation case in #824 does, and this RFC leaves it open.

Adoption Strategy

• Existing sites. No step is required. Every user keeps a built-in role and role_id is NULL.
• Rollout. The migration adds a table and nullable columns. Code deployed before it ignores them. Code deployed after it treats a NULL role reference as a built-in role.
• Plugin authors. Declare a permission on each route, as the plugin documentation already describes, and avoid comparing ctx.user.role.
• Documentation. The role table in the authentication guide stays valid for built-in roles. A new page covers custom roles, the seed format and the compatibility level.

Implementation Plan

Phase	Content	Schema change
1	The single check. Permission names replace the role comparisons in the user-management routes and in MCP, with a new Admin-level name where none exists yet. Effective permissions in /auth/me. useCan in the admin. Plugin page visibility by permission. The equivalence test.	None
2	Roles table and references. Collection scope in content routes, cross-collection reads and MCP tools. The roles API, the seed section and the CLI. Role slugs in identity-provider mappings. Allowed token scopes derived from grants. Custom roles in the user role picker.	Additive
3	The role editor: a permission matrix that starts from a built-in role as a template. Documentation.	None

Each phase is a separate set of pull requests, and phase 1 can be accepted without the others. I can implement phases 1 and 2.

Unresolved Questions

• Loading the role row. Two candidates address the round-trip goal: a join in the query that loads the user, or the object cache with invalidation on role writes. The object cache is optional and off by default, so by itself it does not meet the goal on every site.
• Own drafts only. Every role with content:read_drafts sees all drafts, revisions and trashed entries of a collection. A role for external users, such as the one Feature Request: Declarative Admin Sidebar Navigation (Grouping & Role Guards) #2317 describes, may need to see only its own entries. A sketch: content:read_drafts keeps meaning all drafts, and an additional permission limits list and get to entries whose author_id is the actor. The column is indexed, and the filter is one predicate. It touches list queries, so it is left out of phases 1 to 3.
• Splitting write permissions. The grant model does not depend on the current names. If create, update and delete should be separate for more resources than content, that is an additive change to the map that custom roles would use directly.
• Admin-level permissions in custom roles. plugins:manage, schema:manage, settings:manage, backups:manage and the transfer permissions each need a decision on whether holding them amounts to full control of the site.
• Plugin page visibility. Derived from the backing route or declared on the page. Let a plugin admin page declare a minimum role, so the sidebar hides it from roles that cannot open it #3034 is the place for that decision.
• Visual editing. Edit mode on site pages stays tied to the role number, so a role whose compatibility level is below Author, such as jobs-editor, gets no inline editing. Whether edit mode should ask for a permission, and for which collections, is open.
• The Subscriber floor. Whether every custom role should be required to contain the Subscriber permissions, which would remove the exception in the compatibility level.
• Compatibility level after a core upgrade. A permission that a release adds to the map at or below a custom role's compatibility level is not part of that role, so the role no longer contains the level it is stored at. Whether the stored level is derived again, which can lower it, or kept, which leaves it above what the role contains, is open.
• One role per user. Several additive roles per user is the alternative.

Future Possibilities

• A locale scope on content grants, for translators.
• Tokens that carry a role narrower than their owner's, as Support role-constrained API tokens for admin-panel E2E testing #2358 requests.
• A grant that decides which plugins a role may reach, mirroring the mcp:tools:<pluginId> token scope.
• Scopes for other resources, such as media folders and taxonomies.

[masonjames]

Thanks for putting this together. I’m building a paid-content plugin with an editor panel and a few admin pages, so I have a couple of thoughts from that side.

I agree with keeping public members out of scope. In my plugin, a reader’s access follows their Stripe subscription and is checked on each read. There’s no role to assign. Keeping reader accounts separate from staff roles makes sense to me.

I have two questions about plugin editor panels and collection-scoped roles. My plugin adds a “Paid access” panel to the entry editor, where you set who can read the post. It saves through a plugin route, and I’d want whoever can publish that post to be able to set its access rule.

1. As I read it, plugin routes declare a permission without a collection. That means jobs-editor couldn’t call a route requiring content:publish_any, even from a jobs entry. Could the host check that route against the collection of the entry being edited? The collection would need to come from context the host trusts, not from the plugin’s request body.
2. Could Block Kit editor panels use their backing route’s permission to decide visibility in phase 1, the same way Block Kit pages would? That would show the panel to people who can use it. Native panels and list columns still have the minRole limitation already covered under Drawbacks.

Both requests would use existing core permissions. I agree with leaving plugin-defined permissions out of scope.

[ascorbic]

I've added a complementary proposal: #4132

[github-actions[bot]]

Design PR #4156 proposes proposals/custom-roles.md for this Idea. Review of the design continues on the pull request.

[nickchomey]

Thanks for putting together such a thoughtful proposal. I'm evaluating Emdash for a multilingual knowledge and learning platform, and custom roles with collection-scoped permissions would address a lot of what we'd need.

I had a few questions about possible future extensions. Apologies if I've missed something in the RFC or if any of these would conflict with its design.

1. Multiple roles per user

I noticed the proposal currently assumes one role per user, with additive roles listed as an alternative under the open questions.

Would it make sense to support multiple roles, or at least leave the data model open to that possibility?

For example, someone might be a translator for one set of collections, an editor for another, and a publisher for a third. If each combination requires a separate custom role, I wonder whether this could lead to quite a few roles over time.

WordPress, for comparison, supports multiple roles per user internally, as well as direct user capabilities. I'm not necessarily suggesting that Emdash needs both, but additive roles seem like they might be useful.

2. Locale-scoped permissions

I saw this mentioned under future possibilities, and it would be particularly valuable for multilingual publishing.

For example, a translator might be allowed to edit Spanish translations of articles and lessons without being able to modify the English originals or publish their own changes.

Would the proposed collection-scoped permission model be reasonably extensible to include a locale constraint later, or would that require a more substantial redesign?

3. Draft visibility and editorial assignments

I also noticed the open question about restricting contributors to their own drafts.

That seems important if contributors aren't all part of the same trusted editorial team. Ideally, an author could see their own drafts, while an assigned editor or reviewer could access the drafts they're responsible for.

I realize this overlaps with the separate co-owners proposal and potentially a more comprehensive editorial workflow. I'm not sure how much belongs in RBAC itself, but it would be good if the current design could accommodate that kind of access later.

4. Plugin permissions

I'm also wondering about custom permissions defined by plugins.

For example, a course-management plugin might introduce actions like reordering lessons, assigning reviewers, or approving translations, which don't necessarily map neatly to existing core permissions.

Would there eventually be a way for plugins to register their own namespaced permissions and have them appear in the same role-management interface?

Related to this, I noticed the discussion about collection-scoped permissions on plugin routes and editor panels. That seems important if plugins are expected to extend Emdash's content-editing capabilities.

I certainly wouldn't want any of these considerations to hold up the initial implementation. The proposed collection-level RBAC would already be a substantial improvement.

I'm mainly curious whether these scenarios fit naturally into the proposed architecture, even if they are addressed in separate RFCs later.

Thanks again for the work on this!