Your workflows broke after upgrading Alfresco?

[angelborroy]

When Hyland plugged MNT-21638, a remote-code-execution hole in the Activiti script task, the patch shipped in ACS 7.3.0 quietly changed the execution sandbox. Workflows deployed from inside the repository (via Share, Admin > Workflow Console or a simple file upload) lost direct access to Java and now throw the exception:

ScriptException ... ReferenceError: "java" is not defined

Later versions (from 7.3.1 to 23.4.x) even blocked some task-listener scripts because of a follow-on bug tracked in MNT-24913

Below is the fastest way to decide whether you’re affected and the resolution path that works for every known cause.

Am I affected?

Affected versions: 7.3 to 23.4.x

Deployment methods affected:

• Deployed with Admin > Workflow Console
• Dropped in Data Dictionary folder

Database flag:

SELECT category FROM act_re_deployment

returns Null/empty (it must return http://alfresco.org/workflows/fullAccess)

Why the DB check? The MNT-24913 fix simply falls back to that category flag when the Activiti execution context isn’t yet available. So if the flag is missing, your script will stay locked down even after upgrading.

The one-stop fix

Package every workflow as a class-path deployment and give it the fullAccess category.

Do not waste time poking Rhino or reverting patches, this is the only approach blessed by Engineering and it keeps you secure from the original RCE.

Here’s the minimal setup:

1. Place files on the classpath

$CATALINA_BASE/shared/classes/alfresco/extension/
├── myProcess.bpmn20.xml
└── myProcess-context.xml

2. Skeleton Spring context

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN"
"http://www.springframework.org/dtd/spring-beans.dtd">
<beans>
  <bean id="my.workflowBootstrap" parent="workflowDeployer">
    <property name="workflowDefinitions">
      <list>
        <props>
          <prop key="engineId">activiti</prop>
          <prop key="location">alfresco/extension/myProcess.bpmn20.xml</prop>
          <prop key="mimetype">text/xml</prop>
          <prop key="redeploy">false</prop>
        </props>
      </list>
    </property>
  </bean>
</beans>

Mounting or copying these two files into the container gives the process full Java access again.

3. Verify

SELECT category
FROM act_re_deployment
WHERE name_ = 'myProcess.bpmn20.xml';

It should return http://alfresco.org/workflows/fullAccess

If the row is missing, restart ACS; the bootstrapper sets it on startup.

Version-specific edge cases

• Still on < 7.3 (unpatched RCE): Jump straight to 25.1 or the latest LTS
• Working with 7.3 to 23.4.x and DB flag present but task-listener scripts fail: Apply the hot-fix for MNT-24913 (available for 23.3.5) or upgrade to ACS 25.1+ where the fallback logic is merged
• Need a quick test: Run a dummy script task "logger.log(java.lang.System.getProperty('java.version'))". If it executes, you’re good

Take-aways for dev teams

1. Bundle BPMN + context in your build pipeline; treat workflows like code, not content.
2. Smoke-test upgrades with a script task that calls a harmless Java class, you’ll catch sandbox regressions instantly.
3. Monitor "act_re_deployment.category", a missing flag means someone bypassed the standard deploy path.
4. Stay current: the patch cadence is steady, and Hyland no longer back-ports most script-engine fixes beyond the current LTS.