Enable image editor in Image and File fields with versioned save to the referenced content

[erickgonzalez]

Description

The new image editor is currently available only in Binary fields. Extend it to Image and File fields.

Availability:

Field type	Image editor available?
Binary	When the selected file is an image (existing behavior)
Image	Yes
File	Only when the selected file is an image

⚠️ This supersedes the earlier note in EPIC #34420 ("For File Field, shouldn't be available"). The epic's field-availability table is being updated to reflect that File fields do get the editor when the file is an image.

Save behavior — updating the referenced content:

Image and File fields work as a reference to another content (a file-asset contentlet). When a user edits the image and saves a new version, that change must propagate to the original referenced content:

• Saving the edited image creates a new version of the original file-asset content (in place, via the standard check-in so version history is preserved).
• Because the asset is shared, any other content that references the same file-asset will see the updated image. This is the intended behavior.

Acceptance Criteria

Availability

• The image editor option is available in Image fields
• The image editor option is available in File fields only when the selected file is an image
• The image editor option is hidden in File fields when the selected file is not an image
• Binary field behavior is unchanged (editor available when the file is an image)

Save / version propagation

• Editing the image and saving creates a new version of the original referenced file-asset content
• The new version is persisted via the standard content check-in (version history preserved; previous version recoverable)
• After saving, the field reflects the updated image
• Other content referencing the same file-asset shows the updated image (shared-asset behavior)
• Editing from an Image field and from a File field both update the same referenced file-asset correctly

Edge cases

• Saving without making edits does not create a spurious new version
• If the user lacks edit permission on the referenced file-asset content, the save is prevented with a clear message

Suggested Tests

This work spans front-end (editor availability) and back-end (versioned check-in of the referenced file-asset), so coverage is broader than the FE-only tickets. Unit-first, then Integration/Postman for the save path, with a single E2E smoke.

Unit (FE — Jest/Spectator) — availability logic

• Image editor option is shown for an Image field
• Image editor option is shown for a File field when the selected file is an image
• Image editor option is hidden for a File field when the file is not an image (parameterized across non-image types)
• Binary field availability is unchanged (shown only when the file is an image)
• The image-vs-not detection used to gate the option behaves correctly for common extensions/mime types

Unit (BE — JUnit) — save path

• The save service resolves the field's referenced file-asset content and builds a check-in for a new version (mocked APIs)
• A no-op save (no image changes) does not trigger a check-in
• A user without edit permission on the referenced content is rejected before any check-in

Integration (dotcms-integration) — versioning behavior (the highest-value layer here)

• Editing + saving an image referenced by an Image field creates a new version of the referenced file-asset contentlet, with prior version recoverable
• Same via a File field updates the same referenced file-asset correctly
• A second content referencing the same file-asset reflects the updated image (shared-asset behavior)
• Save is blocked when the user lacks edit permission on the referenced content

Postman (dotcms-postman) — REST contract

• The endpoint used to save the edited image checks in a new version of the referenced content and returns the expected payload/inode
• Permission denial returns the expected error status

E2E (Playwright) — one focused smoke only

• Open content with an Image field pointing at an image → open the editor → make an edit → save → the field shows the updated image. (Single happy path; per-field-type availability and the version/permission matrix are covered by unit + integration, so no broader E2E.)

Priority

Medium

Additional Context

Part of the new Edit Contentlet work (dotCMS: New Edit Contentlet) and the Image Editor migration (EPIC #34420 — kept as a related reference, not a parent link). The key technical consideration is that Image/File fields are references to a file-asset contentlet, so the editor's save path must check in a new version of that referenced content rather than mutating field data in isolation. This is why the work spans both front-end (editor availability + wiring) and back-end (versioned check-in of the referenced asset).

[github-actions]

PRs linked to this issue

• feat(edit-content): enable image editor in Image and File fields (#36363) by @oidacra