#20942: Remove custom file field maximum files limit and improve UX on attached files creation / edition / deletion

Scope & Context

We use Twenty CRM to manage records that require attaching multiple files (photos, documents, scans, media, etc.) to individual records via custom FILES fields. Currently, Twenty enforces a hard limit of maximum 10 attached files per FILES field, which is far too restrictive for many business use cases across industries (property management, construction, legal, medical, event planning, etc.).

Additionally, the current file attachment UX suffers from critical usability issues: files are displayed by their random internal File IDs instead of human-readable names, renaming is cumbersome, and there are no quick actions (inline delete, clear gallery view). This severely limits the practical usage of the FILES field type and prevents building useful workflows on top of attached files (e.g., image processing, document generation).

Current behavior

1. FILES field hard limit at 10

In Settings > Data Model, when editing a custom FILES field and trying to set "Max values" above 10, the UI rejects the input with the validation error:

maxNumberOfValues must be defined in settings and be a number greater than 0 and less than or equal to 10

<img width="1083" height="299" alt="Image" src="https://github.com/user-attachments/assets/3dbab1db-e4a4-4c49-8cc2-594ff7e63271" />

2. File IDs displayed instead of names

In the record detail view, custom FILES fields display attached files using their internal File UUIDs (e.g., f47ac10b-58cc-4372-a567-0e02b2c3d479) instead of the original uploaded file name (e.g., contract-final.pdf, kitchen-photo.jpg). These UUIDs are meaningless to end users and make the search/filter box in the field completely useless, as no user can search for or recognize a random ID.

<img width="375" height="247" alt="Image" src="https://github.com/user-attachments/assets/3ec5d7d5-2060-433e-8626-976d7c8e7da4" />

3. No inline delete action

There is no quick way to remove an attached file directly from the custom field. Users must navigate elsewhere or use a multi-step process to detach a file. This slows down day-to-day operations significantly when managing galleries or document sets. Without any preview, we cannot recognize what file is with the UUID only.

<img width="318" height="224" alt="Image" src="https://github.com/user-attachments/assets/f0004251-76e5-41a1-844f-a7babd7c6e4b" />

4. Cramped, text-only file display

Files are rendered in a very compact, plain-text list format that provides no visual overview. For image files, this makes it impossible to quickly identify which file is which without clicking through each one individually.

<img width="1253" height="45" alt="Image" src="https://github.com/user-attachments/assets/031d4609-7f58-4e8c-a063-fec52a3025a3" />

Expected behavior

1. Remove the artificial FILES field attachment limit

• Custom FILES fields should not have an artificial hardcoded ceiling of 10.
• Either: remove the hard maximum entirely for custom fields, letting the user decide how many files they need.
• Or: replace the hard block with a soft warning when exceeding a reasonable technical threshold (e.g., a dismissible tooltip saying "Attaching many files may affect record loading performance"), while still allowing the user to proceed and save their setting.

2. Display and edit human-readable file names

• In the record detail view, custom FILES fields should display the original file name (or an editable display name) instead of the internal File ID UUID.
• The file name should be editable inline by clicking on it, transforming into a text input field. This would finally make the field's search box useful, as users could search by recognizable names like kitchen, bedroom, contract, invoice.

We can imagine a "small" media-gallery feature when you upload files and you can give them a name while they keep the original fileid internally.

3. Quick actions (delete on hover)

• On hover over a file item in the custom FILES field, a small × (delete) icon should appear, allowing users to detach the file from the record with a single click.
• A lightweight confirmation (e.g., a tooltip "Click again to confirm" or a 2-second undo toast) would prevent accidental deletion.

4. Clearer file gallery / list visualization

• Provide a more visual layout for attached files. For image files, a thumbnail grid or a preview list with small thumbnails would drastically improve usability compared to the current compact text list.
• Non-image files should still show an icon + filename in a clean, scannable list format. [figma screenshot / figma link: A grid of image thumbnails within the record detail panel, each with a filename label below and hover actions]

Technical inputs

• Frontend validation: The Zod schema enforcing maxNumberOfValues <= 10 is hardcoded in the field settings form component. Remove this artificial ceiling for custom fields, or replace the hard validation with a soft warning tooltip.
• Backend validation: Ensure the GraphQL API and the metadata sync/validation logic accept and persist values greater than 10 (or unlimited/null) for custom fields without rejecting them.
• Field rendering (Detail view): Update the FILES field type renderer to fetch and display the File entity's name property (or a user-editable displayName) instead of rendering the raw fileId UUID.
• Inline renaming: Add an onClick handler on the file name label that swaps it with a controlled <input>. On blur or Enter key, trigger a mutation to update the file's name in the database.
• Delete action: Add a hover-revealed delete button next to each file item that calls the existing detach/remove file mutation.
• Search indexing: Update the search/filter logic within the FILES field dropdown to query on the file's name column rather than (or in addition to) the id column.
• Gallery view: Consider rendering image files with a small <img> thumbnail (using the existing file URL/presigned URL) in a responsive flex/grid layout instead of a plain vertical text list.