'Some data cannot be retrieved' error when nested fields are loaded with external actions post patching for VMSA-2024-0001

Products

• VMware Aria Suite

Issue/Introduction

Symptoms:

• A patch for VMSA-2024-0001 has been applied and the affected blueprint form has nested fields which are populated by external actions.
• On loading the form the following error is present in the UI:

Some data cannot be retrieved. If the problem persists, contact your system administrator. Failed request: "<ModuleName>/<ActionName>"

• Leveraging the browsers developer tools a 403 unauthorized error present.
• The 403 Unauthorized error is also present in the forms service logfiles located under /var/log/services-logs/prelude/form-service-app/file-logs/form-service-app.log

DEBUG form-service [host='form-service-app-8c6445c95-rrf62' thread='parallel-1' user='<Username>' org='<OrgID>' trace='TraceID' parent='' span='<SpanID>'] o.s.b.a.w.r.e.AbstractErrorWebExceptionHandler - [<id>] Resolved [ResponseStatusException: 403 FORBIDDEN "Action execution not allowed."] for HTTP POST /form-service/api/forms/renderer/external-values

Environment

VMware vRealize Automation 8.x

Resolution

The issue is resolved in the Aria Automation 8.16.1 release

Workaround:

You can modify the blueprint to workaround the issue.

1. Create a new blueprint, ensuring the old one remains unchanged until the fix is implemented. This way, you won't lose the initial state of the original blueprint.

2. Alter the newly copied blueprint considering the following blueprint structure:

formatVersion: 1

inputs:
  objectInput:
    type: object
    properties:
      textField:
        type: string
        $data: /data/vro-actions/com.vmware.library.snmp/getData?input=testInput
        $dynamicDefault: /data/vro-actions/com.vmware.library.snmp/getDynamicDefault?input=testInput
        $dynamicEnum: /data/vro-actions/com.vmware.library.snmp/getDynamicEnum?input=testInput
resources: {}

3. To resolve the issue, copy the nested field, maintaining the exact structure, naming, and everything else exactly the same, to the top level.

4. The new field is set as readOnly to avoid distracting the user, and this is the only difference between two fields. The modified structure will look like this:

formatVersion: 1
inputs:
  textField:
    type: string
    $data: /data/vro-actions/com.vmware.library.snmp/getData?input=testInput
    $dynamicDefault: /data/vro-actions/com.vmware.library.snmp/getDynamicDefault?input=testInput
    $dynamicEnum: /data/vro-actions/com.vmware.library.snmp/getDynamicEnum?input=testInput
    readOnly: true
  objectInput:
    type: object
    properties:
      textField:
        type: string
        $data: /data/vro-actions/com.vmware.library.snmp/getData?input=testInput
        $dynamicDefault: /data/vro-actions/com.vmware.library.snmp/getDynamicDefault?input=testInput
        $dynamicEnum: /data/vro-actions/com.vmware.library.snmp/getDynamicEnum?input=testInput
resources: {}

Moving forward, any modification made to the inner field must also be applied to the corresponding new field at the top level. The two fields must always match. Although the new field is readonly and appears as such on the form, this serves as a workaround to the problem. Repeat this process for each nested object field whose value is loaded via an external value.