System-managed fields cannot be renamed — createdAt/createdBy/updatedAt/updatedBy stay in English on every record page

[petrbaloun]

Bug description

Standard fields can be localised by writing standardOverrides.label via
updateOneField — that works and the frontend honours it (thanks!). But the server
rejects the same mutation for system-managed fields:

FIELD_MUTATION_NOT_ALLOWED:
Cannot edit system-managed field "createdAt" properties: label

Four of those fields are shown on every record page: createdBy, createdAt,
updatedBy, updatedAt. They render as "Created by", "Creation date", "Updated by",
"Last update" next to fully localised ones, so a Czech workspace ends up with a form
that is half translated. The same applies to the system reverse relations
attachments, taskTargets, noteTargets, timelineActivities (less visible —
hidden-field list and relation pickers).

Twenty's own i18n does not cover these labels either: the workspace member locale is
cs-CZ and they still render in English, so there is no path to a fully localised
record page today.

Steps to reproduce

1. Workspace with locale: cs-CZ, self-hosted v2.24.1.

2. Localise a normal standard field — works:

   mutation { updateOneField(input: { id: "<company.domainName>",
     update: { label: "Web" } }) { id label } }
   

3. Try the same on an audit field:

   mutation { updateOneField(input: { id: "<company.createdAt>",
     update: { label: "Vytvořeno" } }) { id label } }
   

   → FIELD_MUTATION_NOT_ALLOWED.

4. Open any record page → the "Record" field group still shows English labels.

Expected behavior

label is presentation-only and should be editable even on system-managed fields —
the restriction makes sense for name, type or isNullable, but not for a display
label. Alternatively, ship these labels in the i18n bundles so locales cover them.

Environment

Server v2.24.1 (Elestio, Docker), SDK 2.23.0, workspace locale cs-CZ.

[sonarly[bot]]

🟢 Sonarly Analysis — Low Severity

Guard blocks localization of system-managed field labels

System-managed fields reject label updates before the standard-field override path runs, preventing fully localized record pages.

Root Cause

The proximate cause is an API-layer guard in sanitizeRawUpdateFieldInput. When isSystemSideEffect === true and the request is not a system build, every submitted property is rejected unless it is in FLAT_FIELD_METADATA_SYSTEM_SIDE_EFFECT_EDITABLE_PROPERTIES. That allowlist contains only isActive:

if (existingFlatFieldMetadata.isSystemSideEffect === true && !isSystemBuild) {
  const forbiddenUpdatedProperties = Object.keys(updatedEditableFieldProperties)
    .filter((property) => !['isActive'].includes(property));

  if (forbiddenUpdatedProperties.length > 0) {
    throw new FieldMetadataException(
      `Cannot edit system-managed field "${existingFlatFieldMetadata.name}" properties: ${forbiddenUpdatedProperties.join(', ')}`,
      FieldMetadataExceptionCode.FIELD_MUTATION_NOT_ALLOWED,
    );
  }
}

Therefore label is rejected before the normal standard-field logic can process it as an override [ref:toolu-bash-origin-sanitize]. The later standard-field path explicitly includes label in the standard editable-property list and sends overridable properties through the metadata override computation [ref:toolu-bash-editable-list] [ref:toolu-bash-origin-sanitize]. This explains why ordinary standard fields can be relabelled while system-managed fields cannot.

The triggering state is that the targeted audit fields are marked as system-managed. The canonical system-field definitions include createdAt, updatedAt, createdBy, and updatedBy with isSystem: true [ref:toolu-read-partial-system] [ref:toolu-bash-origin-system-fields]. A later workspace upgrade command backfills isSystemSideEffect: true for pre-existing system fields, explicitly including those eight reserved fields [ref:toolu-bash-652]. The exact reported error proves that the guard condition was active for the requested field and that label was classified as forbidden.

Git history attributes the rejecting guard to commit 1be5a0e54a35922afa8096adf872c3aafcb94e1c; the commit directly modified both the system-side-effect editable-property constant and sanitize-raw-update-field-input.ts [ref:toolu-bash-blame]. Its commit description confirms that the restriction was deliberate to prevent direct mutation of engine-owned system fields, but it also states that presentation divergence was intended to be handled later through an override framework [ref:toolu-bash-1be-description]. The defect is that the guard is applied before that presentation-only override path, so it protects structural properties and labels equally.

The Czech locale bundle contains translations for the canonical audit labels in the inspected mainline source [ref:toolu-bash-cs-translations]. That may affect the separate English-display symptom, but missing i18n entries are not the cause of the mutation rejection.

Blame commit: 1be5a0e5 by prastoin — System side effect relations (#22882)

Suggested Fix

No files were changed. The exact defect exists in commit 1be5a0e54a35922afa8096adf872c3aafcb94e1c and its descendant code, where the system-side-effect guard permits only isActive before standard-field override processing. The production fix should update that guard's editable presentation-property handling—at minimum allowing label (and preferably the complete field presentation override set)—while preserving protection for structural properties. The current checkout predates that code path, so implementing only part of the fix here would not protect users and could create an incomplete metadata model.

---

Analyzed by Sonarly · View full analysis