[Bug] WfRoleStoreAjax returns JSON without Content-Type: application/json header, causing legacy Tasks portlet workflow modal to hang in Firefox

Problem Statement

Problem Statement
When opening a workflow task in the legacy Tasks portlet, the modal triggers an XHR to:

GET /DotAjaxDirector/com.dotmarketing.portlets.workflows.ajax.WfRoleStoreAjax
    ?searchName=<name>&roleId=<uuid>&start=0&includeFake=false

The endpoint returns HTTP 200 with a valid JSON body, e.g.:

{
  "identifier": "id",
  "label": "name",
  "items": [
    {
      "name": "<role display name>",
      "id": "<role uuid>"
    }
  ]
}

However, the response is sent without a Content-Type: application/json header on this code path. Firefox falls back to parsing the body as XML, fails on the very first character ({), and logs:

XML Parsing Error: not well-formed
Location: .../DotAjaxDirector/com.dotmarketing.portlets.workflows.ajax.WfRoleStoreAjax?...
Line Number 1, Column 1

The Dojo data store wired to this XHR never receives a successful parse, its onComplete callback never fires, and the modal's auto-close-on-success handler — which is gated on that same callback chain — never runs.

Net effect: the modal stays visible indefinitely after a workflow action has already completed.

This is purely a UI/header bug. The backend successfully completes the workflow execution: catalina logs cleanly show:

INFO  business.WorkflowAPIImpl - Needs reindex, adding the contentlet to the index at the end of the workflow execution
INFO  business.WorkflowAPIImpl - Added contentlet to the index at the end of the workflow execution, dependencies: false

Steps to Reproduce

1. On any build with the legacy Tasks (Workflow Tasks) portlet, open the portlet in Firefox with Developer Tools open.
2. Click any task to open its workflow modal.
3. Observe in the Console: XML Parsing Error: not well-formed against the WfRoleStoreAjax?... URL, line 1 column
4. Observe in the Network tab: the request returns 200 OK with a valid JSON body. Switch to the Headers tab — Content-Type: application/json is absent from the response headers.
5. Fire any workflow action from the modal (e.g. an Approve / Publish action).
6. Observe: the action completes successfully on the server (verifiable in catalina.out — WorkflowAPIImpl logs the workflow execution and re-index), but the modal does not auto-close. The user must dismiss it manually.

Acceptance Criteria

• All code paths in WfRoleStoreAjax that write a JSON response set Content-Type: application/json (with charset=UTF-8) before the response body is written / committed.
• Firefox no longer logs XML Parsing Error: not well-formed against WfRoleStoreAjax when opening a workflow task modal.
• The workflow action modal in the legacy Tasks portlet auto-closes after a workflow action completes successfully, in both Firefox and Chrome.
• Manual smoke test passes in Firefox and Chrome on a build containing the fix.

dotCMS Version

dotCMS version: 26.03.13 and likely earlier

Severity

Low

Links

FreshDesk Ticket: https://dotcms.freshdesk.com/a/tickets/36239

Affected file:

dotCMS/src/main/java/com/dotmarketing/portlets/workflows/ajax/WfRoleStoreAjax.java
The class contains more than one code path that produces a JSON response. The Content-Type header appears to be set correctly on a later path but not on the earlier path that handles the role-search / role-by-id lookup exercised when a workflow modal is opened.
Suggested fix shape (illustrative):

response.setContentType("application/json");
response.setCharacterEncoding("UTF-8");
// ... existing JSON write

This matches the pattern already in use elsewhere in the same class.
While in this area, it is worth scanning sibling *StoreAjax / *Ajax classes in com.dotmarketing.portlets.workflows.ajax (and adjacent legacy Dojo AJAX packages such as com.dotmarketing.portlets.browser.ajax) for the same pattern. This is a small fix and the same defect may exist in other classes that pre-date the convention of setting Content-Type explicitly on every JSON response path.

Useful Resources

• Roadmap context: the legacy Dojo Tasks portlet is on the Dojo→Angular modernization track. This fix is a low-risk, surgical change worth landing now rather than waiting for the rewrite, since it unblocks a concrete, reproducible UX issue today.
• Possibly adjacent (NOT a duplicate): role/permission caching work in the auth area — related code surface but a different defect class.

Start in dotCMS/src/main/java/com/dotmarketing/portlets/workflows/ajax/WfRoleStoreAjax.java and inspect every JSON response path, especially the role-search and role-by-id lookup used when opening the modal. Confirm each response sets the JSON content type and UTF-8 encoding before writing, then manually exercise the legacy Tasks portlet in Firefox and Chrome to verify the parsing error is gone and the workflow modal auto-closes.