Nintex Forms: 188.8.131.52
We have a document library that allows user uploads. To keep things simple I want to hide a bunch of "admin only" fields during the initial upload.
I set these field's visibility to the expression-
fn-Not(Is New Mode)
but when I test it, the fields are always visible.
In Sharepoint, uploading a document to a library is a 2-stage process, you upload the file and then you set the properties in a separate "edit properties" form. I think the reason for the issue is that the property edit form is never in "New Mode", because it is always editing the properties of a document that already exists, even if it was created <2s ago.
Ok, I have a workaround.
This particular library has a workflow attached that sets the value of a "Submitted" date field. It turns out, in the 2-stage Sharepoint upload process for documents in Sharepoint, the On Create or On Update workflows don't trigger until AFTER the second form (the document properties) has been submitted, so by looking for a NULL (blank) Submitted field, I can detect the document is in the process of being uploaded for the first time, and hide the "extra" fields.
It's not ideal having to rely on a workflow rather than the form being able to detect directly it's in the equivalent of "New Mode", but it works.
To generalise this it would perhaps be cleaner to have a separate Yes/No field called something like "Init" that the workflow sets after the docuent is created, rather than relying on a side effect of a field that's used for another purpse, but that would mean you were extra data columns to the library just to make the forms work correctly.
Another consideration with SP2013 libraries is that if you don't have a required field, the OnCreate workflow doesn't wait for the upload form to be modified and closed - it runs in parallel. A required field seems to be the only thing that prevents the OnCreate workflow from running until after the new/edit form has closed.
We're seeing this in multiple cases where we need to know when we're editing first time or subsequent time. real bummer though for processing.
Yes, I have spent many weeks off and on writing test workflows to try to fully understand the "life cycle" of documents in Sharepoint libraries (as regards when workflows trigger etc.)
It's complex, ugly, and as far as I can tell undocumented.
Having struggled with nasty hacks involving timeouts (that get you into horrible problems with race conditions) I now have a general workflow design that works reasonably well when-
However there are still several "edge cases" where certain circumstances or user actions can cause things to fail. One is if the user uploads a file and then either goes home for the day or cancels-out of the property edit form.
This leaves you with a document library item with all the properties missing, including the mandatory ones. This leaves the file stuck in the checked-out state and blocks any workflows from running, and there doesn't seem to be any automated way to recover from it.
You bring up a good point about the undocumented activity - and the ensuing frustrations that result. Included in this is the subtle difference in processing for an Uploaded document vs one added by Drag & Drop. And SP2013 relies on the Drag & Drop method to upload multiple documents. But unless one can process the required fields during the "load" process, they sit checked-out and workflow processing won't even begin until they're checked-in.
Unfortunately I have yet to discover an indicator pointing to whether a document is "uploaded" or added using Drag & Drop. I'm curious as to how your process accounts for this difference in behavior.
I'm afraid it doesn't. Our users rarely use drag+drop in day to day activity, so I can get away with it. D+D is most often used for bulk uploading or copying/moving multiple files, but as you've noted you can't supply the file metadata that way, and if there are any mandatory fields the files all need to have the metadata added and then checked-in after upload anyway, It's not pretty, and it's been like this since the early days of Sharepoit I believe.