Directus 11.17.4 — user_created field returns 403 FORBIDDEN in client-side filters/fields for non-admin roles

Help
,
1

Environment: Directus 11.17.4, self-hosted Docker, MariaDB

Problem: Any API request from a non-admin role that includes user_created in the filter or fields parameter returns 403:

GET /items/MyCollection?filter[user_created][_eq]=
→ 403: “You don’t have permission to access field ‘user_created’ in collection ‘MyCollection’ or it does not exist.”

GET /items/MyCollection?fields=user_created
→ 403 (same error)

Requests without user_created work fine:

GET /items/MyCollection?limit=1 → 200 ✓
GET /items/MyCollection?fields=id,date → 200 ✓
GET /items/MyCollection?filter[date][_eq]=…-> 200 ✓

Setup:

  • user_created exists in directus_fields (special: user-created, interface: select-dropdown-m2o)
  • Column exists in DB table (char(36))
  • M2O relation registered in directus_relations
  • Permission row has user_created in the fields list
  • Policy is correctly linked via directus_access
  • directus_users READ permission is present for the policy

What I’ve tried (none fixed it):

  • Setting permission fields to *
  • Widening directus_users READ to permissions: {}, fields: *
  • Removing special: user-created from directus_fields
  • Unhiding the field
  • Restarting Directus after each change

Key observation: The server-side permission filter {“user_created”:{“_eq”:“$CURRENT_USER”}} works correctly — it scopes results to the current user. Only
explicit client-side use of user_created in query params triggers the 403.

Workaround: We strip user_created from client-side filters/fields before sending and rely on the server-side permission filter for isolation.

Question: Is this intended behavior in 11.17.4? Is there a configuration we’re missing, or is this a regression?

if you do GET /items/MyCollection?limit=1 Does the response include a user_created field?

 –

yes /items/MyCollection?limit=1 - response contains the user_created field with the UUID of the user.

 –