Skip to main content

I have a workflow that will assign a review task on a per document basis to users. This workflow also raises the permissions for the reviewer to a contribute level for the duration of the task. The workflow itself works fine.

I wanted to avoid a case where the reviewer would complete the task (and return permissions to normal) but leave the document checked out (potentially without the ability to check it back in).

I can build this into the workflow to kick back to the user requiring check-in before proceeding with permission restoral in the workflow. However I thought it would be cleaner to validate the check-in at task form. I created a Nintex Task form to validate the "OK" button if the document was checked out to that user or not.

The validation part works fine, however, now when the document is checked in, the form passes validation but now I  get the error that ..."XXXX.docx is not checked out.  You must first check-out this document before making changes." 

None of the document fields were enabled and I even tried removing all of the controls except the task controls.

I don't have this issue with the default form, but then I don't have the validation.

Why and what is the form trying to update on the item that doesn't work when the document is checked in?

Note: In versioning 'Check out required to edit' is enabled and if I do change it to "not required"  all works fine work. However this is not something I can change for the actual libraries this will be used.

Anyone else run into this and have a workaround? 

Thanks

SB

Where you are getting the error, exactly after which step? The below might be helpful which happened in my requirements.

But after task has been approved, do you have any Update any column information of document library? Or is your workflow just ends after the approval task? If so workflow might be trying to update the default workflow column option with a status Completed, and which can't be done without check out.


could you share how exactly you implemented validation? 


Hi again Marian,

The Review Task assignees are set as variables at the start form. I have it set up for three reviewers max, each with an individual review task running parallel to control permissions uniquely for each user as tasks are completed. (as soon as one reviewer is complete, their increased permission level is clawed back but the others remain open until they are done)

For validation, on the task form's "OK" button (set to "continue" decision), the control is invalidated if  "Document Checked Out User"="the user in that task's reviewer variable"

This is would be to ensure they check it back in before their permissions are revoked but if it is checked out to someone else it is validates fine.

SB


I will also add the even with the default Nintex form this error occurs. It seems I cannot submit a task form on a checked in item when check-in/check-out is set to required in the library using a Nintex form. It does work with the same workflow using the default Sharepoint form. The Nintex start form work just fine.

Anyone else see this?


from what I understood I tried to reproduce your scenario, however, I was able to respond the task regardless of whether I used SP standard form or nintex form and regardless of document check in/out status or who had the document checked out. library setting ' Require documents to be checked out before they can be edited' was to yes.
since was not sure what you mean with 'Task review' (there is no such workflow action) I tried it with 'Request review' and 'Assign flexi task' action. both could respond the task.

can you provide more details what your workflow is exactly doing?
what are the circumstances you get the error? - I mean who is workflow initiator,  who is task assignee, who has  document checked in/out, etc.

do you experience the same problem with just one approver (no parallel approvals)?


Hi again,

It is indeed the "Request Review Action"

Versioning is set to 'Require documents to be checked out before they can be edited' 

I have now created a one action workflow with the "Request Review Action" and the default Nintex form.

I  even ran this with a freshly created a barebones library with the basic "document" content type and still get this issue.

Scenario 1.

I am the workflow initiator, I am the Task assignee.

Document was checked in to start workflow. Document is never checked out during the workflow. I get the error when I respond to the Task.

Scenario 2.

Same as above except another user with contribute access to the library and workflow task list is the assignee.

Same error in both scenarios. If I change 'Require documents to be checked out before they can be edited' setting in versioning to no, then it goes through fine. It also works if I check out the document and then respond.

I am running 3.0.8.0 so maybe there is a difference there which is why it is working for you. Perhaps there is a setting somewhere either Sharepoint or Nintex that I, as more of an end user, do not have access to.

This is the first time I have tried using a Nintex form for a task. Ironically the reason I wanted to use it (to ensured documents are checked in) is the reason it is not working.

I do appreciate you trying this out.


Soni,

My original reply to you isn't there, or maybe it didn't save. I tried your suggestion of disabling the status column and even custom history messages and still run into the issues.

Thanks for the suggestion though. That seemed like a very logical reason that it might not be working .


I've tried both your scenarios, both with standard and nintex form, but can not reproduce the error.

I'm not sure what might be different with your setup.


Thanks for trying Marian. I guess for now though not ideal I will just use the workflow to ensure it is checked-in and kick it back to the user there. Just curious though what version you are running?

Thanks again.

SB


NF 2.7.0.0

NW 3.1.10.0


Hi Marian Hatala, Soni Reddy,

So, I recently was able to get this issue solved happy.png(for me at least). I had to revisit this and although by no means scientific or totally exhaustive, here is what I noticed/did.

Assuming, the default Nintex task form properties controls are the same as the input controls,  although they are disabled they seem to be submitting the data back causing my issue of it needing to be checked out. I have run into this before and seen it mentioned in other posts.

Previously, I deleted all of the item properties controls (leaving the labels) figuring nothing would be submitted if there were no property controls on the form at all. This still did not solve the issue, and I was still getting the error requiring it to be checked out. In a moment of clarity I noticed that the default Nintex task form also had layouts for smartphone, mobile, tablet. etc. and that they were linked to the original item property controls on the Desktop Layout. (I have only ever been concerned with and or manipulated the Desktop layouts so I never really paid much attention to the other layouts)

After deleting the property controls on the Desktop Layout, I deleted all of the other layouts except for Desktop, and now the form would work with the document checked in.

I reloaded the default form, left all the layouts but deleted the item property controls from ALL of the layouts and it worked with document checked in.

I left all of the layouts and deleted all of the item property controls except for just one on the smartphone layout, and back came the error.

So... although I was using the Desktop Layout, and had deleted the property controls (and even labels) on that layout, the item property controls on the other layout seem to be what was giving me grief. Perhapss some relationship remained to the controls on the other layouts even though they were deleted on the layout being used. In the end, I deleted the layouts I don't need, deleted all of the item property controls and replaced them with labels/reference data. I am happy I can get this to work, and get this info in my tool chest.  But, is this the expected behavior? I would still consider myself a novice on this but it does seem a little counter-intuitive. Any thoughts?


Reply