dotCMS / dotCMS/core

Large Message workflow sub-action: Message/body content not rendered in modal

Open
#37,530 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

OKR : Customer Support
Dominant language
Java
Stars
970
Forks
486
Avg merge
3d 33m
Merged PRs (30d)
170

Description

Problem Statement

A workflow action's Large Message sub-action renders its Title correctly but never displays the configured Message/body content in the modal, making the sub-action unusable for its primary purpose on affected versions. Confirmed via network inspection that the correct message content is delivered to the client but not applied to the modal.

The modal displays only the Title. The Message/body area is empty, regardless of whether the message content is plain text or HTML.

Steps to Reproduce
  1. On an existing workflow scheme (reproduced on the Blog and default System workflows on demo.dotcms.com; also reproduced on a custom workflow scheme in a customer environment), add a Large Message sub-action to any workflow action.
  2. Configure the sub-action with: User IDs = Current User, Message = TEST (also tested

    TEST

    as HTML — same result), Title = Test Preview, Width = 50%, Height = 90%, Language = java, Code = empty.
  3. Save the action.
  4. From the content edit screen, fire the workflow action.
  5. Observe the resulting modal.
  • Reviewed LargeMessageActionlet/processMessageValue source (dotCMS/core, master branch): confirmed message is always processed and set independently of code/lang — those two only add an additional code block when both are set, and don't suppress or interact with message. Ruled out as the cause.
  • Exported the workflow scheme JSON and confirmed the message parameter is saved correctly server-side.
  • Cleared cache — no change.
  • Inspected the DOM at modal-open time: the message content is genuinely absent from the rendered DOM, not present-but-hidden via CSS.
  • Delivery happens via a persistent connection (shows as a single long-lived "events" entry in the browser Network panel rather than a discrete per-fire request). Inspecting that connection's individual pushed frames confirmed a body: "TEST" frame is delivered to the client with the correct content — so the data reaches the browser but isn't applied to the modal.
  • That connection showed unusually long Stalled (~1.1 min) and Content Download (~1.9 min) phases for what should be a near-instant push.
  • Title reliably updates correctly on every fire, isolating the defect specifically to the Message/body not being applied, rather than a broader modal-rendering failure.
  • Reproduces identically in both Chrome and Firefox — not browser-specific.
Acceptance Criteria

The modal displays both the configured Title ("Test Preview") and the Message/body content ("TEST").

dotCMS Version
  • dotCMS versions: v26.08.19-04 and v26.09.09-01 appear to be broken
  • local environment running v25.07.02-1 is working as expected
Severity

Medium - Some functionality impacted

Links

NA

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reading LargeMessageActionlet/processMessageValue and reproduce the workflow action with the supplied TEST message. Trace the client-side handling of the delivered body frame and modal rendering, then verify that the modal shows both the configured title and message content in the affected versions.

Written by the indexing model from the issue text.

Assessment

Tech stack
java
Domain
frontend
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
63/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.