Skip to content

Workflow Viewtool initializes as an anonymous user in Velocity Script actionlet #35347

@jdcmsd

Description

@jdcmsd

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:

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
  1. Add a Velocity Script actionlet to a workflow action
  2. Ensure the Velocity Script actionlet uses the $workflowtool.fire() method to fire a workflow action NOT accessible to an anonymous user
  3. Fire the action containing the Velocity Script
  4. See error

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

Metadata

Metadata

Assignees

No one assigned

    Type

    Projects

    Status

    New

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions