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

[Neehakethi]

Problem Statement

Non-admin users receive permission denied when adding or editing languages via Available Languages > Locales, even when their role has the Locales portlet assigned in Tool Groups.

Impact: Any role that was given only the "Locales" portlet (the current UI-visible option) cannot perform add/edit locale actions. Admins are unaffected because they bypass portlet checks. This blocks customers who rely on role-based access (e.g. Privacy Admin, content managers) from managing locales.

Reported: Customer (Newell Brands – privacy.newellbrands) – users with "Privacy Admin" role can view Locales but get permission denied when clicking "Add Locale" or editing. Browser/OS: Chrome, Mac.

---

Root Cause

Mismatch between frontend and backend portlet IDs:

1. Frontend / Tool Groups (portlet.xml ~line 432): Exposes the "Locales" portlet (modern implementation). With FEATURE_FLAG_LOCALES_HIDE_OLD_LANGUAGES_PORTLET=true (default), the old "Languages" portlet is hidden from the list (RoleAjax.java ~lines 101–102, 632–635).
2. Backend API (LanguagesResource.java): All language/locale operations use .requiredPortlet(PortletID.LANGUAGES.toString()) (e.g. lines 224, 247, 347, 373, 521, 595). So the backend only accepts users who have the "languages" portlet.
3. Result: Admins assign "Locales" to a role; backend still checks for "languages". Non-admins fail; admins succeed because they bypass portlet checks in LayoutAPIImpl (e.g. CMS Admin fallback).

---

Steps to Reproduce

1. As admin, create a role (e.g. "Privacy Admin") and assign only the Locales portlet in Tool Groups (do not assign "Languages" – it is hidden by default).
2. Create a user and assign that role. Ensure the user is not CMS Admin.
3. Log in as that user, go to Available Languages > Locales.
4. Click Add Locale (or try to edit an existing locale) and submit.
5. Expected: Action succeeds.
   Actual: Permission denied / access denied error.

---

Acceptance Criteria

• Users with the Locales portlet (and no "Languages" portlet) can add and edit locales without permission errors.
• Behavior remains correct for users who have only "Languages" or both portlets (backward compatibility).
• No regression for admin users or for permission checks on other portlets.

---

dotCMS Version

Observed in customer environment; codebase applies to current main (feature flag and Locales portlet are present). Version: Latest from main / Cloud – please confirm exact version from customer if needed.

---

Severity

High – Major functionality broken for non-admin roles that are explicitly given Locales access.

---

Links

• Freshdesk ticket #35336 – Permissions in privacy.newellbrands Site (Locales access denied for Privacy Admin role)

---

Suggested Fix (from engineering review)

Option A (recommended): Update backend to accept either PortletID.LOCALES or PortletID.LANGUAGES when enforcing permission for language/locale operations (e.g. in LanguagesResource and any other places that use .requiredPortlet(PortletID.LANGUAGES.toString())). This is backward compatible and fixes the mismatch without migrating permissions.

Option B: Migrate all roles that have "Languages" to also (or only) have "Locales", then change the backend to check only "Locales". Requires data/UI migration and config.

Temporary workaround for customers: Set FEATURE_FLAG_LOCALES_HIDE_OLD_LANGUAGES_PORTLET=false, restart, then assign both "Locales" and "Languages" portlets to the role. Not ideal (exposes legacy portlet and requires restart).