Hi All,
First, some background: many of us still remember a time when using validations based on uploaded document properties (name, extension, size, etc) in a!fileUploadField() was not "officially" possible and therefore some of us were forced to resort to unsupported functionality to access these properties from just-uploaded documents, for various use cases. The most common use case, of course, was validating that uploaded files were of the correct type (extension), and thankfully a few versions ago, Appian added the fv!files property to the component, to access the important properties of uploaded documents.
Unfortunately, the fv!files feature was was only added to the Validations parameter, leaving a few other use cases not "officially" possible using supported functionality. To me, the most obvious of these use cases is:
I want to have a text field next to my a!fileUploadField component, which will pre-populate with the name of an uploaded document, and will be editable by the end user. The value of that field will then be used within the "fileNames" parameter of the file upload field, in such a way that any edits made by the user are saved as the uploaded document's name within Appian. (Note: to clarify, the specific part of this scenario that isn't possible is the ability to pre-populate the name of an uploaded file into another variable for use in a text field.)
Therefore, it would be incredibly useful if the saveInto Parameter could access the fv!files data in such a way as to allow us to duplicate any of the contained properties off to other rule inputs, local variables, etc.
Other use cases could include setting external variables due to specific extensions being uploaded, or specific sizes or size ranges, etc - there are probably dozens of valid edge cases that this feature would satisfy which now aren't possible unless using unsupported workarounds. Additionally, from an outside perspective at least, I would think this would have a high likelihood of being a low-effort add on the part of Appian's product engineers, since it would in certain ways duplicate the functionality currently enabled in the validations parameter of this component.
Everyone please let me know what you think.Thanks!
Discussion posts and replies are publicly visible
Sad to see there's still no movement on this, even though there are posts in Community at least once every few weeks asking how to do something which would be easy if this were implemented, but impossible (or requires unsupported workarounds) without...
Hi Mike, there is a possible solution that allows you to solve this without any need for plug in.Simply evaluate an additional fileupload field in the save into and index into values.I have provided an example below:(Here, PRO_UXL_Index is simply performing a repeated index. You can of course simply wrap 3 layers of index() around the fileUploadField instead).I hope this helps, until Appian provide a robust solution. Of course, the same solution can be used for extensions.
a!fileUploadField( label: "File Upload", labelPosition: "ABOVE", value: ri!documents, maxSelections: 2, saveInto: { ri!documents, a!save( target: ri!fileNames, value: touniformstring( rule!PRO_UXL_Index( data: a!fileUploadField( label: "File Upload", labelPosition: "ABOVE", value: ri!documents, maxSelections: 2, saveInto: ri!documents, validations: {} ), path: { "contents", "value", "fileName" }, default: {} ) ) ) }, validations: {} )
That is an already known and dirty hack that could break any time. Definitely NOT recommended.
a!submitUploadedFiles is a better more stable approach for customers on the recent Appian version, but this component can be used and updated (when version is increased) for customers on older versions of appian. As, clearly, there is no chance of it breaking between eg 21.X and 22.1 (which i when i think it was added).
MR O R G POWER said:evaluate an additional fileupload field
I used this trick (encapsulated into its own expression rule) to grab the uploaded file's extension, many years ago - back before the 'fv!files' capability was added to the Verifications parameter, because we HAD to verify on uploaded extension and there was NO other way to do so at that time. But I abandoned that as soon as an official method became available.
My current workaround (for your situational awareness, in case it helps) uses much less of an unsupported approach than this - namely, the getContentObjectById plug-in function can get a set of details (in plaintext) from any doc ID, whether or not just uploaded - so I have a special expression rule designed to grab the filename of a just-uploaded file when needed, and break it down into name and extension (which is a giant pain in the butt to parse, tbh). But my overall point with this feature request post, of course, is that these extreme (and/or less-extreme) workarounds should NOT be necessary in a robust system with robust capabilities.