HI team,
i want to find the type of extension and Size of list of documents and i have used document function and build an expression rule it is working fine in expression rule as expected when i call that expression in an interfcae it is shoowing error as document function is deleted.
a!localVariables( local!size: a!forEach(ri!documents, document(fv!item, "size")), local!extension: a!forEach( ri!documents, document(fv!item, "extension") ), toboolean( and(and(reject( fn!isnull, { a!forEach( local!extension, if(fv!item <> "pdf", false, null) ) } )), and(reject( fn!isnull, { a!forEach( local!size, if(fv!item > 5000000, false, null) ) } ) ))) )
when i use in interface getting error as shown below
Discussion posts and replies are publicly visible
Was the document just uploaded by the user on the very same interface?
yes
This is what I expected based on your error description. Documents which have just been uploaded on the same interface are not available to the normal set of document parsing functions, including "document()", and trying to call it will result in an error.
This is because, prior to the form being submitted, the documents are actually stored in a special place in the Appian File System that we don't have access to from the front-end (including the design side).
Only after the task is submitted, are they moved out of that reserved space and into their target upload folder, at which point you can call "document()" on them.
I would add, also, that the File Upload Field has a built-in way to validate on Extension and Size of uploaded files, so there should be no need to implement your own version of it at this point.
Yes i have did but i have a requirement where i want to disable a button on the above mentioned conditions
NewBegineer said:i want to disable a button on the above mentioned conditions
Unfortunately until something like my Ancient Feature Request is implemented, there is no direct supported way to do this with freshly-uploaded files. The linked feature request would, of course, enable this use case as well as many other things. If you feel so inclined, please visit that old thread, upvote it, and add a comment detailing your use case.
cc Peter Lewis (are there any engineers finally ready to take this on as their "free time project"?)
There has been some discussion on this internally, but I don't have much of an update at the moment unfortunately. Like Mike said, the best approach at the moment is still to validate using fv!files, and keep adding your use cases.
For instance, I'd be very interested in understanding more about this use case why it is important to disable the button over using the out-of-the-box validation behavior (where it prevents form submission).
Peter Lewis said: I'd be very interested in understanding more about this use case why it is important to disable the button over using the out-of-the-box validation behavior (where it prevents form submission).
I can do the "devil's advocate" position on this one pretty easily: it's often desired to have a "Save Changes" button which skips *most* validations but still validates some more important things (for instance, validating that some text fields don't contain database-breaking lengths, or that there aren't files in place that would be problematically large). Since the simple "validation group" concept doesn't actually handle this, one of my personal favorite workarounds is disabling the "save changes" button when something exists that shouldn't be saved. (There was an entire debate about this just earlier this morning in the Discord). But for this use case, of course, even that isn't directly possible.
Yeah that's a good use case, the context is helpful! I always appreciate a good use case because it gives a better picture into what the overall goal is - like in this case it would be great to have improvements to both validations AND document previews