* Describe the bug
In the built-in users collection, field-level permission restrictions are not enforced on write operations when the field is rendered inside the user profile block.
I configured a role (“unternehmen”) with full access to all records in the users collection, but explicitly set the field “firstName” to no permissions (no read, no write, or any other kind of access). The field correctly appears empty in the profile view (read restriction works). However, when I type a value into the field and save, no error is shown and the value is silently persisted to the database. Only after I grant read access to the field does the written value become visible — confirming the write was accepted despite the restriction.
The bug does not reproduce in a freshly created general-purpose collection with identical permission settings — it appears to be specific to the built-in Users collection.
* Environment
- NocoBase version: 2.0.53
- Database type and version: PostgreSQL 16
- OS: macOS Catalina 10.15.8
- Deployment Methods: Docker container
- Docker image version: 2.0.53
- NodeJS version: N/A
* How To Reproduce
- Go to Settings → Roles & Permissions and open any non-root role.
- Under the users collection, grant the role full access to all records.
- In the field permissions for the same collection, set the firstName field
to no permissions (all checkboxes off — no read, no write). - Make sure the firstName field is included in the user profile block
(the page where a logged-in user can view and edit their own profile). - Log in as a user that has this role assigned.
- Open the profile page → the firstName field is visible but empty
(read restriction appears to work correctly). - Type any value into the firstName field and click Save.
- Observe: no error is shown, the save appears to succeed.
- Now go back to the role settings and grant read access to the firstName field.
- Open the profile page again → the value entered in step 7 is now visible.
The value was written and persisted to the database despite the field having no
write permission.
Expected behavior
When a field has no write permission, any attempt to save a value to that field
should be rejected server-side with an appropriate error response. The value must
not be persisted to the database under any circumstance.
Screenshots
[to be added]
Logs
[no server-side error logged — the request appears to succeed silently]