Sites (Host) with individual permissions: non-admin roles with full Publish permission can't see "Save/Activate" — only CMS Administrator can

Problem Statement

A custom (non-admin) role that has been granted full individual permissions (View, Edit, Publish, Edit Permissions) directly on a specific Site/Host does not see the "Save/Activate" action after clicking "Lock for Editing" on that Site's edit screen — they only see "Release Lock". A CMS Administrator sees both "Release Lock" and "Save/Activate" on the same Site with no other config changes. This means there is currently no supported way for a non-admin role to save/activate a Site, regardless of how its permissions are configured — full Site-level Publish permission is necessary but not sufficient.

Root cause (traced in code):

1. The "Save/Activate" button is hardcoded markup in contentlet_actions_inc.jsp (~lines 212-230), gated by canPublish && isHost.
2. canPublish correctly evaluates true here — Publish is individually granted directly on the Site (PermissionAPI.doesUserHavePermission(contentlet, PERMISSION_PUBLISH, user), edit_contentlet.jsp:183).
3. However, that block sits nested inside a broader div gated by wfActionsAll being non-empty (contentlet_actions_inc.jsp:165), where wfActionsAll = WorkflowAPI.findActions(wfSteps, user, contentlet).
4. findActions permission-filters through WorkflowActionUtils.filterActions (WorkflowActionUtils.java:71-114). Lines 76-80: CMS Administrator bypasses this filter entirely and gets all actions back unconditionally. Non-admins must instead have PERMISSION_USE on a workflow action object (a separate permission tree from Site object permissions).
5. Host/Site content is simultaneously excluded from the workflow engine (WorkflowAPIImpl.findAvailableActionsEditing/isActionAvailable short-circuit to empty/false for Host content type) — so there is no scheme/action a non-admin could ever be granted PERMISSION_USE on for a Site, since Sites don't participate in workflow at all.
6. Net effect: wfActionsAll is always empty for non-admins on Sites, so the entire action toolbar (including the hardcoded Save-Activate block) never renders for them — independent of their actual Site permissions. Only the CMS Administrator's blanket bypass avoids this.

Steps to Reproduce

https://github.com/user-attachments/assets/9c7b5549-7142-47b7-8e8d-b3e1aa23d780

Detailed steps:

1. Create a custom (non-admin) role.
2. Select or create a Site.
3. On that Site's own Permissions tab, grant the role individual permissions: View, Edit, Publish, Edit Permissions — all checked.
4. Clear the permissions cache (Maintenance → Cache).
5. Sign in as a user with that role (or use "Sign in As").
6. Open the Site, click "Lock for Editing".
7. Observe: only "Release Lock" is available; "Save/Activate" never appears.
8. Repeat as a CMS Administrator on the same Site: both "Release Lock" and "Save/Activate" appear.

Acceptance Criteria

• A non-admin role with full individual Publish permission on a Site sees "Save/Activate" after locking for editing, matching CMS Administrator behavior.
• No regression to the existing CMS Administrator bypass behavior for workflow-gated content types.

dotCMS Version

26.08.10-01

Severity

Medium - Some functionality impacted (workaround exists: grant CMS Administrator, but that's over-privileged)

Links

• Freshdesk ticket #38757
• Slack thread

Start in contentlet_actions_inc.jsp and trace wfActionsAll and the Save/Activate rendering, then review permission checks in edit_contentlet.jsp and WorkflowActionUtils.java. Compare the Host-content paths in WorkflowAPIImpl.findAvailableActionsEditing and isActionAvailable; done means a non-admin with Site Publish permission sees Save/Activate while CMS Administrator workflow behavior remains unchanged.