[oidacra]

Summary

The legacy content type editor (/ext/structure/edit_structure) saves content types with the
permissions of the logged-in user, applying the same checks as the content type REST endpoints.
Making a content type the default one requires EDIT_PERMISSIONS stored for it. A requested content
type the user may not read, or that does not exist, gets the same fixed answer.

Changes

• EditStructureAction:
  • Saves through the new StructureFactory.saveStructure(Structure, User), which uses
    APILocator.getContentTypeAPI(user):
    • every save needs permission to add children and to edit content type permissions on the
      site or folder the type is saved on (the destination one for a new type or a move);
    • an existing type also needs EDIT_PERMISSIONS on it.
  • Saves workflow schemes only after the type itself was saved.
  • When the user may not save the type (including the default content type lookup that runs
    first), nothing is changed, the page shows message.insufficient.permissions.to.save, and
    the refusal is written once to the security log.
  • Loading the requested type: when the user may not read it, or no type has the posted inode,
    the page shows dont-have-permissions-msg and returns to the referer or the content type
    list. Only the refusal is logged. A posted inode that matches no type is no longer saved as a
    new type.
  • cmd=SET_DEFAULT: a refusal shows dont-have-permissions-msg and is logged; any other
    failure is logged as an error and shows an-unexpected-error-occurred.
• StructureFactory:
  • New saveStructure(Structure, User). It sets the saved inode on the structure and sends the
    same save event as saveStructure(Structure).
  • saveStructure(Structure) is unchanged for its callers (jobs, push publishing, upgrade tasks,
    the field editor). It shares a private helper with the new method.
• ContentTypeAPIImpl.setAsDefault:
  • Requires EDIT_PERMISSIONS in the permissions stored for the type, with the API's
    respectFrontendRoles flag.
  • Its only caller is the legacy editor.

Tests

• Unit:
  • EditStructureActionTest (12): the user's permissions are used; no schemes and no cache update
    after a refused save; one message and one security log entry for a refused save, a refused
    set-default and a refused load; an unknown type gets the same answer with nothing saved and no
    log entry; data errors are not reported as refusals, and a set-default data error shows a
    fixed error message.
  • ContentTypeAPIImplSetAsDefaultTest (4): only the stored permissions count.
• Integration: EditStructureActionSaveTest (12), driven through processAction with stored
  permission rows.
  • Refused, with the type, its schemes and the default type unchanged: saving, moving or changing
    the workflow schemes without EDIT_PERMISSIONS on the type; creating on, or moving to, a site
    without add-children; set-default without EDIT_PERMISSIONS stored for the type.
  • Opening a type without READ shows the fixed message, not the error page; posting an inode that
    matches no type creates nothing.
  • Allowed, for a non-admin with the required permissions: edit, move, change schemes, create
    with a scheme, set default.
• Registered in MainSuite2a, the shortest compatible suite. Median job runtime over 5 recent
  merged PRs (test(ci): stop the Postman and Karate stacks sleeping 3 s per write #38226, fix(postman): serve by-URL fixtures from WireMock and seed the language Content_Version_Resource needs #38213, fix(ci): tolerate transient network failures in SDKMAN, pnpm and image pulls #38210, fix(ui): restore native Array.from so Stencil attributes reach props on legacy pages (#35291) #38182, fix(docker): drop the compromised emSign ECC Root CA - G3 from the JDK truststore #38176): 2a 23.7 min, 1a 38.2 min, 1b 43.3 min,
  2b 44.5 min, 3a 45.7 min.

Risk

• The legacy editor requires the same permissions as the content type REST endpoints and the
  Angular editor: add-children plus content type edit-permissions on the type's site or folder for
  every save, and EDIT_PERMISSIONS on an existing type.
• No layout lists the legacy editor on current versions.
• setAsDefault requires EDIT_PERMISSIONS stored for the type.
• A request for an inode that matches no content type is answered like a refused one; no screen
  sends such a request.
• No schema, index or REST contract change.

Fixes dotCMS/private-issues#889

[claude]

Claude finished @oidacra's task in 2m 33s —— View job

---

Code Review

Reviewed the diff against origin/main. This enforces the caller's permissions in the legacy content type editor, matching the REST/Angular editors. The implementation is sound.

Verification notes:

• ContentTypeAPIImpl.setAsDefault now requires PERMISSION_EDIT_PERMISSIONS (was READ). I confirmed the only non-test callers are the legacy editor (EditStructureAction:495) and the deprecated StructureFactory shim. The pre-existing integration tests that call it (HostAPITest, ContentTypeAPIImplTest) all use systemUser, which short-circuits doesUserHavePermission, so they won't regress.
• StructureFactory: the public no-user saveStructure(Structure) still routes through the system-user typeAPI and re-wraps DotSecurityException into DotHibernateException, so jobs/push-publish/upgrade-task callers keep their privileged, unchanged behavior. The new user-aware overload lets DotSecurityException propagate — correct.
• save() fires pushSaveUpdateEvent only after a successful save, so a refused save emits no event and performs no write. Good.
• The permission gate is on the type save itself (contentTypeAPI.save() is reached even for an unchanged save), so the permission-free saveSchemesForStruct at EditStructureAction:338 is correctly gated behind it — a scheme-only edit still must clear the type save first.
• Load path: a READ denial (DotSecurityException) is logged and shows dont-have-permissions-msg; a non-existent inode (NotFoundInDbException) shows the same message without logging. Both produce the same user-facing answer, so existence isn't leaked. Matches the stated intent.
• respectFrontendRoles is a Boolean field set from a primitive constructor arg, so the auto-unbox at ContentTypeAPIImpl:666 can't NPE.

New Issues

• 🟡 Medium: dotcms-integration/src/test/java/com/dotcms/MainSuite2a.java:68 — EditStructureActionSaveTest is inserted into the middle of @SuiteClasses (per commit 430dbf69), but CLAUDE.md / the Integration Tests guide direct new registrations to be appended at the end of the list. Non-blocking, but it diverges from the documented convention. Fix this →

No correctness, security, or error-handling issues found in the changed code.
· legacy-content-type-editor-saves-as-user

[swicken]

Looks good. The legacy editor now loads, saves and sets the default content type with the logged-in user's permissions, and a type the user can't read gets the same answer as one that doesn't exist. Internal callers keep the no-user saveStructure overload, and EditFieldAction already checks PUBLISH before its save. setAsDefault now needs EDIT_PERMISSIONS rather than READ, which applies to every caller of ContentTypeAPI, not only the legacy editor; that looks intended. Since erick's approval the only changes are merges from main and the MainSuite2a registration move. CI is green.