Bug: User relational fields (user_created/user_updated) render as [object Object]

[smartlabsAT]

Summary

User relational fields — most notably the system fields user_created and user_updated, but also any many-to-one relation pointing at directus_users — render as [object Object] (or as a bare UUID) instead of a human-readable user name.

Current Behavior

When a user field is loaded as a nested object (e.g. { id, first_name, last_name, email }) and no matching display template resolves for it, the cell falls through to the raw-value fallback, which stringifies the object:

String({ first_name: 'Jane', last_name: 'Doe', email: '…' }) // → "[object Object]"

As a result the column shows [object Object]. When only the id is loaded, the bare UUID is shown instead of a name. This is especially visible on the built-in user_created / user_updated columns, which users frequently add to tables.

Expected Behavior

User fields should render a friendly, readable label using a clear fallback chain:

1. Full name — first_name + last_name when available
2. Email — the user's email if no name is set
3. ID — the user id/UUID as a last resort
4. Never [object Object].

Empty / null values should render the standard empty placeholder (—).

Nice-to-have: optionally show the user's avatar next to the name, matching the native Directus user display.

Acceptance Criteria

• user_created / user_updated columns show the user's name (or email/id fallback), never [object Object].
• Any M2O field targeting directus_users behaves the same way.
• A user with only a first name or only a last name renders cleanly, with no stray whitespace.
• A user object missing both name and email gracefully falls back to the id.
• Null / empty values render the empty placeholder (—), not [object Object].

Technical Notes

• Rendering happens in src/components/EditableCellRelational.vue. The [object Object] originates from the final fallbacks that call String(value) (the raw-value spans) once no display has resolved for the field.
• A dedicated branch for user fields — detected via field.display === 'user' and/or a relation to directus_users — that formats the value as name → email → id before reaching the raw-value fallback would resolve this cleanly.
• For optional avatar support, the avatar reference must be included in the requested fields when building the query (see src/utils/adjustFieldsForDisplays.ts).