Document Name Storing with document name, extension and size instead of only document name.

Question

Hi, 
 I am validating just uploaded document size with below code: 
 if( rule!APN_isBlank(ri!documentId), 
 { fullName: null(), name: null(), ext: null(), size: tointeger(null()) }, 
 a!localVariables( 
 local!value: a!fileUploadField(value: todocument(ri!documentId), target:cons!RMO_FOLDER_ALL_DOCUMENTS, fileNames: fv!file), 
 local!fileDetails: tostring(local!value.contents.value.filename), 
 local!fileName: extract(local!fileDetails, "[name=", ", extension" )[1], local!fileExt: extract(local!fileDetails, "extension=", ", size")[1], local!fileSize: tointeger(extract(local!fileDetails, "size=", "]")[1]), { fullName: local!fileName & if(rule!APN_isBlank(local!fileExt), "", "." & local!fileExt), name: local!fileName, ext: local!fileExt, size: local!fileSize } ) ) 
 
 Issue: After clicking on submitting button, document name storing as [name=Document Name, extension=docx, size=3752844] instead of only document name in KC. 
 Can anyone let me know how to store only document name instead of all above details in KC.

Danny Verb · Answer

You must index into fv!file such as fv!file.name 
 
 Docs

Mike Schmitt · Answer

I'm failing to understand what you're trying to do. 
 In validations , you have access to fv!file s .size (note spelling, it's "fv!files", not "fv!file"). The Size returns size in bytes. You validate against this. There's no need for the crazy bending-over-backwards you're demonstrating here in your local variable setup. 
 FWIW you really need to insert code like this into a code box for it to retain any sense of readability.

Mike Schmitt · Answer

Unknown said: Can anyone let me know how to store only document name 
 You're misusing the " fileNames " parameter. I can't even tell what you're *trying* to do with it, but what I can tell is that it's directly responsible for the behavior you describe. 
 In short: fileNames is intended as an override for the name(s) of freshly-uploaded file(s). Any text passed into this parameter will become the name(s) of the file(s) upon form submission. The regular default is to not even use this parameter - it's completely optional and only needed if you want to provide an override, for example having the user type a document name to accompany an uploaded file. 
 Instead you're passing in the raw value of "fv!file", which is a dictionary of information containing name, size, extension information for each uploaded file (as you're seeing in the document name being applied to your uploaded files).

Mike Schmitt · Answer

Unknown said: I want to display a error message on the documents which has more than specified size on the documents which are not yet submitted 
 But this is, quite literally, what the validations parameter would do for you. In what way does that normal setup not satisfy your use case?

Mike Schmitt · Answer

Unknown said: Please let me know if there is any other way to validate size on the just uploaded documents? 
 As I asked above - what's wrong with the standard way?

Mike Schmitt · Answer

Unknown said: We are having multiple tabs and uploading documents for each tab. 
 You kinda buried the lede on this one - this sort of detail is something that could be mentioned up-front, IMHO, so we don't have to chase our tails to arrive at how the default configuration fails to satisfy your use case. 
 In general I have to suggest you reconsider this design approach. As we're seeing currently, there's no standard-and-supported way of directly accomplishing this without implementing weird / strong / unsupported work-arounds. 
 FYI, I do have an outstanding Feature Request thread asking for access to the file properties within the SaveInto parameter of the file upload field. Using this (hypothetical) functionality, we could have file upload components assemble an array of uploaded document filesizes, and use that to throw a form-level validation on your interface when the user attempts to submit. I certainly wouldn't mind if you go over there, join on, and add some commentary to float it back to the Community front page and back into peoples' attention ;-) 
 For now... The best I can suggest at this point is to either move all document uploads to one particular tab where validation can occur before submitting, or off to a different task completely. Or, ( and this might be best ) disable tab-changing outright when any new files are present, until the user clicks a "validate files" button, which submits the form and loops straight back to the task (at the current tab) - giving you an effective way of enforcing failed validations. If set-up properly this could be seamless to the end user, and requires only minor additional tweaks in the form and process. 
 Now... In the past I've definitely used your trick of using a FileUploadField pointing to the newly-uploaded file and digging into the back-end details to get information -- but as you're seeing here, it's tricky to do and has unpredictable side-effects, and as it's unsupported usage , it's liable to change (or go away altogether) at any time with no notice .