Asset structure when file is uploaded from the device vs using an asset from the content (e.g. DAM)

[jakub-gawronski-wttech]

When using the inputs.file method, ACM allows to upload the file from the device, which internally uploads the file under the /var/acm (e.g. /var/acm/file/2026/02/04/b84bf24c-93e1-4347-9b00-e93ca96fd818/file.csv.
Such file has the following structure for example:

The jcr:content has a jcr:data binary property which contains the CSV rows, which works just fine.

However, when using an asset which is already uploaded in the content (AKA providing the path as the default input's value) like so:
value = "/content/dam/experience/file.csv", the script fails at the very beginning due to different node structure in the repo, which looks like this:

The jcr:content containing the binary jcr:data property sits lower in the tree, under the file.csv/jcr:content/renditions/original/jcr:content.

Providing such path to the original node in the script (e.g. value = "/content/dam/experience/file.csv/jcr:content/renditions/original") works just fine, but might be counter-intuitive.

Related error:
dev.vml.es.acm.core.repo.RepoException: Cannot read file at path '/content/dam/experience/file.csv' as it does not have content stream!

[krystian-panek-vmltech]

file input was designed to operate on just uploaded / tmp files. your case wan't designed simply. I will do my best to support it elegantly as well :)

[jakub-gawronski-wttech]

Sure. Case we needed it for was using the "Save" feature, which allows to save the script and perform immediate execution on author, and on publish if "Synchronize" checkbox is checked, where a default value for inputs is required.
Unless this "Save" feature could also allow inputs to be chosen before firing, just thinking out loud.