Fix script execution API error when data and config are sent as JSON arrays

[sanjacornelius]

Issue & Reproduction Steps

Executing a script through the API using the documented JSON payload format results in a server error.

Example request:

{
  "data": [{}],
  "config": [{}],
  "sync": true
}

When calling POST /api/1.0/scripts/execute/{script_id} (or the script preview endpoint) with an application/json request body, Laravel automatically parses the payload, causing data and config to be returned as arrays. The controller was always calling json_decode() on these values, assuming they were JSON strings, which results in the following error:

json_decode(): Argument #1 ($json) must be of type string, array given

This behavior is incompatible with the API documentation, which defines both data and config as arrays.

Solution

Added a private getRequestArray() helper to ScriptController and updated both execute() and preview() to use it when processing data and config.

The helper normalizes request values by:

• Returning the value as-is when it is already an array
• Decoding the value when it is provided as a JSON string (maintaining backward compatibility with form-encoded requests)
• Returning an empty array when the value is missing or invalid

This allows both JSON and form-encoded requests to be handled consistently while preserving existing behavior.

How to Test

1. Authenticate as a user with permission to execute scripts.
2. Select a script that can be executed.
3. Send a JSON request to:
   POST /api/1.0/scripts/execute/{script_id}

with the following payload:

{
  "data": [{}],
  "config": [{}],
  "sync": true
}

4. Verify the request completes successfully and the script executes (or queues) as expected.
5. Verify no json_decode() TypeError is thrown.
6. Repeat the test using a form-encoded request where data and config are provided as JSON strings (e.g. data=[{}]&config=[{}]) to confirm backward compatibility.
7. Optionally repeat the same validation against the script preview endpoint to confirm both code paths correctly handle JSON and form-encoded inputs.

Related Tickets & Packages

• FOUR-27789

ci:deploy

Code Review Checklist

• I have pulled this code locally and tested it on my instance, along with any associated packages.
• This code adheres to ProcessMaker Coding Guidelines.
• This code includes a unit test or an E2E test that tests its functionality, or is covered by an existing test.
• This solution fixes the bug reported in the original ticket.
• This solution does not alter the expected output of a component in a way that would break existing Processes.
• This solution does not implement any breaking changes that would invalidate documentation or cause existing Processes to fail.
• This solution has been tested with enterprise packages that rely on its functionality and does not introduce bugs in those packages.
• This code does not duplicate functionality that already exists in the framework or in ProcessMaker.
• This ticket conforms to the PRD associated with this part of ProcessMaker.

[processmaker-sonarqube]

Quality Gate passed

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
No data about Duplication

See analysis details on SonarQube

[Kookster310]

QA server K8S was successfully deployed https://ci-2f81f47e90.engk8s.processmaker.net