Role-Based Access Control
Role-Based Access Control
Section titled “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.
| Role | Main permissions |
|---|---|
admin | Full administrative access where explicitly allowed; manages users, API keys, master data, and all listings. |
moderator | Moderates 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. |
user | Creates 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.
Collection Access
Section titled “Collection Access”The following summarizes collection-level read, create, update, and delete rules. Field-level rules can further restrict individual values.
| Collection | Read | Create | Update | Delete |
|---|---|---|---|---|
users | Authenticated 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 listings | Published 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. |
ratings | Public 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-searches | Admin, or the owning user. | Any authenticated user. | Admin or the owning user. | Admin or the owning user. |
notifications | Admin, or the recipient user. | Any authenticated user. | Admin or the recipient user. | Admin or the recipient user. |
media | Public 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-media | Authenticated 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 locations | Public. | Admin only. | Admin only. | Admin only. |
api-keys | Admin 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/.
Listing Ownership and Publication
Section titled “Listing Ownership and Publication”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
publishedistrue. - 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
authorfield. Only admins and moderators can change itspublishedfield.
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.
User Records and Field-Level Rules
Section titled “User Records and Field-Level Rules”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 action | Rule |
|---|---|
name, phone_number, profile image, role, verification status, rating totals | Field read access is public, subject to the Users collection requiring authentication. |
email | Readable by admins, moderators, and the user themselves. |
nid_number | Readable by admins, moderators, and the user themselves; create/update is admin-only. Detailed identity-verification behavior is documented separately. |
role | Readable by authenticated users; create/update is admin-only. |
verification_status | Readable by authenticated users; create/update is limited to admins and moderators. |
account_status | Update is limited to admins and moderators. |
email_verified | Update is admin-only. |
| OTP fields | Read 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.
Admin Dashboard Visibility
Section titled “Admin Dashboard Visibility”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.
Source Files
Section titled “Source Files”- Users and role definitions:
frontend/payload/src/collections/Users.ts - Listing collections:
frontend/payload/src/collections/ProvidingListings/andfrontend/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.tsandfrontend/payload/src/collections/Notifications.ts - Media collections:
frontend/payload/src/collections/Media.tsandfrontend/payload/src/collections/NIDMedia.ts - API keys:
frontend/payload/src/collections/APIKeys.ts