You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A while back, I created a velocity script actionlet within that allows me to quickly update the Javadocs link when a new evergreen version goes live, via a checkbox in the new Build content type. This stopped working over the last couple weeks, throwing this error:
User 'anonymous user anonymous [ID:
anonymous][email:anonymous@dotcms.anonymoususer]' cannot read action: Publish
Claude investigated and traces this to a regression from a March 31 commit:
Found it. Look at lines 105-111 [of VelocityScriptActionlet.java] — the actionlet always constructs a FakeHttpRequest with no session, regardless of whether you triggered it from the UI. WorkflowTool.init() calls getUser(request) on that fake request, gets no logged-in user, and falls back to anonymous.
The real user IS available in the Velocity context as $user (line 114: "user", currentUser) — but $workflowtool is already bound to anonymous by the time any VTL runs.
Commit 89f3527 from March 31 (PR #35158) changed the actionlet to always build a FakeHttpRequest to fix SecretTool site resolution for background jobs. That fix correctly scopes secrets to the contentlet's site, but as a side effect, WorkflowTool.init() now always gets a fake request with no session, so this.user is always anonymous — regardless of who triggered the action.
Before that commit the request was built differently and your session user came through.
The regression is clear: the FakeHttpRequest should carry the workflow processor's user in its mock session so WorkflowTool.getUser() resolves correctly. The right fix is in VelocityScriptActionlet — put currentUser into the MockSessionRequest, or add a fire(Map, String, User) overload to WorkflowTool (both are small changes). This is the proper path.
That seems plausible to me. Might be an easy fix!
For additional context, here's the script in question:
## This updates the Javadoc vanity url## Only fires when a Build is published## (build must have the checkbox checked)#if($content.structure.velocityVarName=="Dotcmsbuilds"&&$content.updateJavadoc==1)
#set($newcon= {})
#set($dummy=$newcon.put("contentType", "Vanityurl"))
#set($dummy=$newcon.put("identifier", "62ac13ff99bf408271e22b5470a25d8f"))
#set($dummy=$newcon.put("forwardTo", "https://static.dotcms.com/docs/${content.title}/javadocs/index.html"))
$workflowtool.fire($newcon, "b9d89c80-3d88-4311-8365-187323c96436")
$content.setProperty( "updateJavadoc", "0" )
#end
The content identifier just points to a vanity URL; the workflow identifier points to the publish action. So, in plain language:
If it's a Build content type and the checkbox is checked
then create a map to update the javadocs vanity URL with a new forwardTo
And use $workflowtool.fire() to update it
Finally, uncheck the checkbox before the build finishes saving, so no future publish operations will accidentally repeat this.
As you can see, it's a simple script that really just hitches on the $workflowtool call.
Steps to Reproduce
Screen.Recording.2026-04-16.at.11.00.44.AM.mov
Add a Velocity Script actionlet to a workflow action
Ensure the Velocity Script actionlet uses the $workflowtool.fire() method to fire a workflow action NOT accessible to an anonymous user
Fire the action containing the Velocity Script
See error
Acceptance Criteria
Workflow Viewtool should fire with correct permissions when called from inside Velocity Script Sub-Action.
Problem Statement
A while back, I created a velocity script actionlet within that allows me to quickly update the Javadocs link when a new evergreen version goes live, via a checkbox in the new Build content type. This stopped working over the last couple weeks, throwing this error:
Claude investigated and traces this to a regression from a March 31 commit:
That seems plausible to me. Might be an easy fix!
For additional context, here's the script in question:
The content identifier just points to a vanity URL; the workflow identifier points to the publish action. So, in plain language:
forwardTo$workflowtool.fire()to update itAs you can see, it's a simple script that really just hitches on the $workflowtool call.
Steps to Reproduce
Screen.Recording.2026-04-16.at.11.00.44.AM.mov
Acceptance Criteria
Workflow Viewtool should fire with correct permissions when called from inside Velocity Script Sub-Action.
dotCMS Version
26.04.02-01 - 26.04.11-01
Severity
Medium - Some functionality impacted
Links
https://helpdesk.dotcms.com/a/tickets/36734
NA