Home › Forums › Classic DFFS › List item record lock
Tagged: one user update at a time, Record Lock
- This topic has 12 replies, 3 voices, and was last updated 2 years, 11 months ago by Jonathan Stamper.
-
AuthorPosts
-
-
November 29, 2021 at 17:47 #35279
Do you know of any way to create some sort of record lock on an item in the event that multiple users not update the same things.
Scenario: When a request comes in admins can assign themselves as a single lead to that request. Sometimes another admin may come behind and also add themselves causing an overwrite to what the original admin had assigned to them.
I wasn’t sure if you had any ideas or done anything similar.
-
November 29, 2021 at 17:55 #35281
You can use the Check out list items functionality in the Misc tab in EditForm.
Alexander
-
November 29, 2021 at 23:38 #35284
Ah, ok I’ll take a look into that thanks for letting me know.
-
November 30, 2021 at 14:24 #35289
I like the checkout feature, but one word of caution is if you have a Flow running on it you’ll need to consider how they play together.
-
November 30, 2021 at 15:17 #35291
That is really cool! I didn’t know that existed. Fortunately, I’m not using any workflows at the moment but I’m sure I will have to transition to them in the future with SP Online. What sort of hinderances are you referring when using Flow?
-
November 30, 2021 at 15:25 #35293
Just that you need to account that when it moves to “Checked Out” that is considered an update to the item so if you have something triggered on “When an item is modified” it will activate the workflow. You can add a qualifier – something like “If Checked Out is not equal to true” but you’ll have to play around with it. In Flow, you can put it in the very first step of the trigger under Settings/Trigger Conditions. It has an odd syntax – something like “@not(equals(triggerBody()?[‘CheckedOut’],true))”.
-
-
December 1, 2021 at 20:41 #35308
Got it! That makes sense. Thanks for sharing.
I’m running into a separate issue in that the CheckedOut field will sometimes not switch back to No thus putting items in an infinite “checked out by…” even though no one is in it. Any ideas on what I could do to fix that? I was thinking of just setting the checkedOut = No on save or cancel.
-
December 2, 2021 at 01:58 #35313
Oh, I should have read the directions better. I didn’t set the default to No. Should be fixed now.
-
-
December 7, 2021 at 22:12 #35358
So it appears that I’m still having issues where at least 1-3 times a day the Checked Out field will not flip back to No when a user submits or cancels out of a list item.
Are there any additional things I can try and/or test out that may assist?
-
December 7, 2021 at 22:34 #35362
Which version of DFFS are you using in this form?
Alexander
-
-
December 8, 2021 at 15:27 #35366
I’m using the v4.4.5.38 but I just remembered there was a newer version out there.
-
December 8, 2021 at 17:07 #35370
The new version does not change anything related to this functionality.
I’m not sure exactly what could be wrong when the user submits and it is still checked out – could it be that they have manually checked the “Keep the form checked out” button?
Regarding the cancelling out of a form after it is checked out:
This might be a weak point because the code has to catch the navigation away from the form and run a function to toggle the CheckedOut to false. If you close the browser or use the browser navigation buttons to go back it does not catch it – only click on the Cancel button will check it back in.The problem is that it is not possible to run custom code in window.onbeforeunload so I’m not sure I have any other solution than possibly using a FLOW to auto-check in items after some time of it being checked out (if it has not been checked back in while the FLOW was waiting to trigger), but I haven’t thought that completely trough so keep in mind that users might have a form open over time or possibly have checked the “Keep the form checked out”.
Alexander
-
December 16, 2021 at 21:46 #35418
Yeah, it’s still doing it after trying out other things. I’ve hidden the option from the user to keep it checked out on close so it wouldn’t be that causing the issue. I ended up creating a “CheckOut” data sheet list view only accessible by our team to handle any items checked out that shouldn’t be. That’s the only other thing I can think of at this stage. I tried a workflow in SP Designer (still on on-premise) and that tended to create a lot of conflict errors with users so I turned that off.
- This reply was modified 2 years, 11 months ago by Jonathan Stamper.
-
-
-
AuthorPosts
- You must be logged in to reply to this topic.