Skip to content

fix(rest-api): accept locales portlet in addition to languages for language/locale operations (#34685)#35250

Merged
dsilvam merged 2 commits intomainfrom
fix/issue-34685-locales-portlet-permission
Apr 8, 2026
Merged

fix(rest-api): accept locales portlet in addition to languages for language/locale operations (#34685)#35250
dsilvam merged 2 commits intomainfrom
fix/issue-34685-locales-portlet-permission

Conversation

@dsilvam
Copy link
Copy Markdown
Member

@dsilvam dsilvam commented Apr 7, 2026

Summary

  • Root cause: LanguagesResource gated all write/sensitive operations on PortletID.LANGUAGES ("languages"), but the UI only exposes PortletID.LOCALES ("locales") to role assignments — making it impossible for non-admin users with the Locales portlet to add or edit locales.
  • Fix: Added PortletID.LOCALES as a second accepted portlet at all 6 call sites in LanguagesResource (v2). WebResource.InitBuilder.requiredPortlet() already implements OR logic, so no framework changes were needed.
  • Backward compatible: Users with the old "languages" portlet still work; admins are unaffected.

Changes

  • dotCMS/src/main/java/com/dotcms/rest/api/v2/languages/LanguagesResource.java — 4 old-style webResource.init() calls converted to InitBuilder with both portlet IDs; 2 existing InitBuilder calls updated to add the second portlet ID.
  • dotCMS/src/test/java/v2/languages/LanguagesResourceTest.java — 4 new unit tests (one per write endpoint) that use ArgumentCaptor + reflection to assert both "languages" and "locales" are in the required portlet set.

Test plan

  • Run unit tests: ./mvnw test -pl :dotcms-core -Dtest=LanguagesResourceTest — all 10 pass
  • Create a non-admin role with only the Locales portlet assigned; verify the user can add, edit, and delete locales without permission errors
  • Verify admin users are unaffected
  • Verify users with only the legacy Languages portlet still work (backward compatibility)

Refs: #34685

🤖 Generated with Claude Code

…nguage/locale operations (#34685)

Backend portlet check used only PortletID.LANGUAGES while the UI (with default feature flag
FEATURE_FLAG_LOCALES_HIDE_OLD_LANGUAGES_PORTLET=true) only exposes PortletID.LOCALES, causing
permission denied for non-admin users; fix adds LOCALES as an accepted alternative at all 6
call sites using the existing OR logic in WebResource.InitBuilder.

Refs: #34685

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
@claude
Copy link
Copy Markdown
Contributor

claude bot commented Apr 7, 2026

Claude finished @dsilvam's task in 2m 5s —— View job


dotCMS Backend Review

  • Load dotCMS conventions
  • Get Java diff (commits 5e1128c2aa38ff)
  • Run 4 specialized sub-agents in parallel (Security, Database, Java Standards, REST API)
  • Consolidate findings and post review

All four sub-agents returned NO_FINDINGS. The review comment has been updated.

@claude
Copy link
Copy Markdown
Contributor

claude bot commented Apr 7, 2026

dotCMS Backend Review: no issues found.

…or portlet assertions (#34685)

Add getRequiredPortlets() to WebResource.InitBuilder to avoid brittle reflection in tests;
update LanguagesResourceTest to use the compile-safe accessor instead of getDeclaredField.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
@dsilvam dsilvam added this pull request to the merge queue Apr 8, 2026
Merged via the queue into main with commit 74e1291 Apr 8, 2026
49 checks passed
@dsilvam dsilvam deleted the fix/issue-34685-locales-portlet-permission branch April 8, 2026 16:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

AI: Safe To Rollback Area : Backend PR changes Java/Maven backend code

Projects

Status: No status

Development

Successfully merging this pull request may close these issues.

[DEFECT] Non-admin users get permission denied when adding/editing Locales — backend checks "languages" portlet while UI assigns "locales"

2 participants