Skip to content

Role-Based Access Control

This page documents the access rules implemented in frontend/payload. Payload access control is enforced by collection and field access functions. Admin UI visibility is a separate presentation setting and does not, by itself, grant or deny API access.

The users.role field supports three values. It is saved to the authentication JWT, so access functions can check the authenticated user’s role.

RoleMain permissions
adminFull administrative access where explicitly allowed; manages users, API keys, master data, and all listings.
moderatorModerates listings and ratings, updates user records and verification/account status, and accesses verification records. Cannot manage API keys, change user roles, or delete users through the configured collection access rules.
userCreates content while eligible, and reads or changes records according to ownership and publication rules.

New users default to user. Only an admin can create users through the Payload users collection or set/change a user’s role there. Public registration is implemented by a custom endpoint rather than the collection’s create access rule; see the Users collection source for that distinction.

The following summarizes collection-level read, create, update, and delete rules. Field-level rules can further restrict individual values.

CollectionReadCreateUpdateDelete
usersAuthenticated users only; field access further limits some values.Admin only through the collection.Admin, moderator, or the user whose ID matches the document.Admin only.
Providing and seeking listingsPublished listings are readable publicly; authenticated users can also read their own. Admins and moderators can read all. In the Admin dashboard, an ordinary user is limited to their own listings.Authenticated, non-banned users; admins and moderators are allowed.Admin/moderator or the listing author.Admin/moderator or the listing author.
ratingsPublic through the API; admins and moderators can read all. In the Admin dashboard, an ordinary user is scoped to ratings where they are the rated user.Authenticated, non-banned users; admins and moderators are allowed.Admin/moderator or the author of the rating (rated_by).Admin or moderator.
saved-searchesAdmin, or the owning user.Any authenticated user.Admin or the owning user.Admin or the owning user.
notificationsAdmin, or the recipient user.Any authenticated user.Admin or the recipient user.Admin or the recipient user.
mediaPublic outside the Admin dashboard. In the dashboard, admins/moderators can read all and ordinary users are scoped to their own media.Any authenticated user.Admin/moderator or the owning user.Admin/moderator or the owning user.
nid-mediaAuthenticated owner, admin, or moderator.Any authenticated user.Admin/moderator or the owning user.Admin/moderator or the owning user.
Master data, such as amenities and locationsPublic.Admin only.Admin only.Admin only.
api-keysAdmin only.Admin only.Admin only.Admin only.

For the complete rules, see the relevant collection source files under frontend/payload/src/collections/ and shared access functions under frontend/payload/src/access/.

The providing and seeking listing collections use the shared ownedOrPublished read rule:

  • Admins and moderators can read every listing.
  • Public requests can read only listings where published is true.
  • Authenticated users outside the Admin dashboard can read published listings and their own unpublished listings.
  • An ordinary authenticated user browsing through the Admin dashboard is limited to their own listings.
  • Owners can update or delete their listings. Admins and moderators can update or delete any listing.
  • Only admins can change a listing’s author field. Only admins and moderators can change its published field.

Creating a listing requires authentication. The create rule checks the current account status from the Users collection and denies a banned account; admins and moderators bypass this check. This rule applies to listing creation and should not be interpreted as a global ban on every collection or operation.

The shared read helper detects Admin dashboard requests using the referer header. The resulting query constraints are therefore part of the implemented behavior, not a general replacement for field or collection access checks.

Collection access and field access are both applied to user data. For example, ordinary users can read user records when authenticated, but cannot necessarily read every field on those records.

Field or actionRule
name, phone_number, profile image, role, verification status, rating totalsField read access is public, subject to the Users collection requiring authentication.
emailReadable by admins, moderators, and the user themselves.
nid_numberReadable by admins, moderators, and the user themselves; create/update is admin-only. Detailed identity-verification behavior is documented separately.
roleReadable by authenticated users; create/update is admin-only.
verification_statusReadable by authenticated users; create/update is limited to admins and moderators.
account_statusUpdate is limited to admins and moderators.
email_verifiedUpdate is admin-only.
OTP fieldsRead and write access through normal collection operations is denied. OTP endpoints and their workflow are documented separately.

The user profile image field has its own field-level update rule; it should not be treated as equivalent to the ownership rules on the media collection.

Some collections use admin.hidden to hide navigation or collection screens from roles that should not manage them. For example, master data is hidden from non-admin users, while the Users screen is hidden from roles other than admin and moderator. These settings affect the Admin UI only. The corresponding access rules are what protect collection operations through the API.

Likewise, being able to see a record in the Admin UI does not imply permission to edit every field. Field access rules and field-specific restrictions still apply.

  • Users and role definitions: frontend/payload/src/collections/Users.ts
  • Listing collections: frontend/payload/src/collections/ProvidingListings/ and frontend/payload/src/collections/SeekingListings.ts
  • Shared listing read access: frontend/payload/src/access/ownedOrPublished.ts
  • Ratings read access: frontend/payload/src/access/ratingAccess.ts
  • Saved searches and notifications: frontend/payload/src/collections/SavedSearches.ts and frontend/payload/src/collections/Notifications.ts
  • Media collections: frontend/payload/src/collections/Media.ts and frontend/payload/src/collections/NIDMedia.ts
  • API keys: frontend/payload/src/collections/APIKeys.ts