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.
MR O R G POWER said:a!submitUploadedFiles
I too was very excited (at first) about the new possibilities this seemed like it would open for us - until it was pointed out to me by others here that it is intentionally (and i suspect, superficially) disabled when used on a Task or a Start Form - i.e. it will only work on Site and Portal interfaces. That's a terrible disappointment because it would've made certain "abandoned file handling" chores (i.e. removing lines of an editable grid with freshly-uploaded docs attached) a LOT more straightforward.
I am also looking for an approach to save the 2 different file name and compare the type pdf,doc , is there a way to save the extension in save and compare it with another file ? i searched the existing validation of pdf and docs shows we can create a local variable inside the validations to check whether current file is pdf or doc , not sure how it will be accessible in the another uploaded file , any help is greatly appreciated
venkatesanr7469 said:create a local variable inside the validations to check whether current file is pdf or doc , not sure how it will be accessible in the another uploaded file
It won't - the scope of any such local variable would not reach a separate uploaded file, as far as I know. Depending on your exact use case, you might be able to utilize the "content object details by ID" plug-in function as a work-around, though it can be a bit of a pain.