Introduce Hard and Soft batch locks

[SteveBiggs]

It has been requested if an action to lock all files under a userID could be created. E.g. a "select all" button for file locking.

Priority (0 1 8 4) 13 Needs #1732

[SteveBiggs]

I asked for clarification and this relates to a few active transcribers (so cannot deactivate) who sometimes get into trouble by corrupting existing files. If the CC could lock all their files, this would prevent it.

[SteveBiggs]

The specific problem is that some (less computer literate) transcribers have accidently replaced a file with the wrong one, so the file had to be retrieved from a backup. Locking all files for these users would prevent that being possible.

[edickens]

This is why in V1.5 I have requested that a transcriber has a "I have completed and sight checked this batch" button in the upload module. Only this will trigger the email to the SC (not for every upload) but also the batch will be Coordinator locked so that the transcriber cannot do any more to this batch, not even download. This will have the same effect as requested by Steve. But we have to be careful that transcribers learn to realise this and so never "Sign off " a batch so that it remains open to them.

[SteveBiggs]

Eric, note that a batch being Coordinator locked does NOT prevent the transcriber from downloading and therefore unlocking it. The downloading of a file clears ALL locks since it is assumed that the transcriber will use this new version for further actions/corrections.

[Sherlock21]

I have a lot of sympathy with this story/ request, as I spent the whole of one weekend with the CC concerned, trying to recover the original file form the Attic. [and the transcriber concerned was had done this sort of thing several times before}

[edickens]

Perhaps a change in how this works is needed, otherwise I cannot see the difference between the two locks.

[SteveBiggs]

Perhaps. There is some value in knowing who locked the file, but the effect is the same whether CC or transcriber.

[Sherlock21]

You do know who locks the file - as Lock is shown in 2 columns: one for [CC + DM] and one for Transcriber.

[SteveBiggs]

Yes, I was pointing out that there is some value in that (as the only difference in response to EricD) even though the lock action is the same.

[AlOneill]

Surely only a coord can remove a coord lock. If this has changed, I missed it, and the Help is wrong.

[Sherlock21]

The DM profile always could add or remove the CC lock if necessary. I don't know if that also applied to the Admin Manager profile

Essential in the case of having to rectify a mess either together with the CC or instead of with the CC. And of course this does not mean that we are always doing this action - but its there in case of need - as all these overlapping permissions are.

[SteveBiggs]

Alison, I could be wrong, but I don't believe anything has changed with the file lock/unlock functionality.

EricB, when a DM (or Sys Admin) selects 'Manage Counties' it effectively takes on the role of the CC so has all the same actions, including locking/unlocking files.

The issue here is whether the transcriber should be able to unlock and edit a file that was locked by the CC. As I understand it, the primary reason for locking a file is to prevent online edits being overwritten by replacing the file with an offline version that does not have those edits. Hence the need to download the file and make any changes to that version and use it for future replacement. When I as CC, make a correction to a file, the file becomes locked, but it doesn't mean I don't want the transcriber to be able to make future corrections/changes, just to make sure they download the file first.

However, there could be an argument that a CC should have the ability to lock a file to prevent any further change by the transcriber. This would be a separate type of lock.

Steve

Stephen Biggs FreeREG Chairman

On 1 October 2017 at 08:55, Sherlock21 notifications@github.com wrote:

The DM profile always could add or remove the CC lock if necessary. I don't know if that also applied to the Admin Manager profile

Essential in the case of having to rectify a mess either together with the CC or instead of with the CC. And of course this does not mean that we are always doing this action - but its there in case of need - as all these overlapping permissions are.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/FreeUKGen/MyopicVicar/issues/1313#issuecomment-333360191, or mute the thread https://github.com/notifications/unsubscribe-auth/AYIaN8Y25up29IR8se4HFz12YBsnC-abks5sn0VVgaJpZM4PXbpo .

[suffolkroots]

However, there could be an argument that a CC should have the ability to lock a file to prevent any further change by the transcriber.

Yes please

[Sherlock21]

Steve Thank you for the clarification. I know the basic functions, but not the total individual permissions that each title included. I too don't believe the requirements have changed at all - yet. But I agree with Ali -- we need one CC lock which is released by the Transcriber just downloading an online copy so they remain up to date with the one in FR, and another to hold Locked until it is released again by the CC, regardless of the batch having been downloaded.

[Captainkirkdawson]

Given that the current coordinator lock does not differentiate between SC and CC one could conceive of that lock acting differently between CC and SC or alternatively adding a hard lock and the current one as a soft lock that continues to work in the same manner. We have been working with the current process for 3 years so you need to consider carefully how to respond to a issue affecting a few transcribers. Would it be simpler for the SC to upload for these specific transcribers.?

[suffolkroots]

If a transcriber tries to replace a CC/SC locked file it cannot be replaced until the lock is off, which can be done by the transcriber downloading it---which of course, should he OK the download, would overwrite his file and expunge his most recent work. This perhaps was not an intended consequence of this lock?

[suffolkroots]

Would it be simpler for the SC to upload for these specific transcribers?

Yes, of course it would Kirk---will you tell them?!

[SteveBiggs]

If a transcriber has continued working on a file since they last uploaded it, they should realise that if they download the one on the site, it won't have their recent additions. If they don't understand this and cannot be trained, then the only solution would be to gently explain that it is necessary that you do the uploading for them to prevent these recurring problems.

On 2 October 2017 at 09:33, suffolkroots notifications@github.com wrote:

If a transcriber tries to replace a CC/SC locked file it cannot be replaced until the lock is off, which can be done by the transcriber downloading it---which of course, should he OK the download, would overwrite his file and expunge his most recent work. This perhaps was not an intended consequence of this lock?

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/FreeUKGen/MyopicVicar/issues/1313#issuecomment-333472370, or mute the thread https://github.com/notifications/unsubscribe-auth/AYIaN8E2E4cVi8hWJYsmoFQ24em7J56Dks5soJ_pgaJpZM4PXbpo .

[edickens]

I'm working my way through these, and am a bit behind. Referring to Steve's of 1st October. My understanding is that when doing any online Edit, only the Transcriber Lock is set. Downloading does, for the reasons Steve says, then removes this lock. The Coordinator Lock is much harder and prevents the batch from being amended in any way until it is unlocked. It has to be set by a CC and is not set by just making a correction. Eric

[edickens]

PS. A batch with a CC lock should still be able to download it and unset the Transcriber lock if set. But the CC lock should stay if set. The most difficult, but rare, situation, is when a transcriber is adding to a batch at the same time as an online edit is done which sets the Transcriber lock. They then cannot upload their new work. They need to download but not overwrite their work, and then add their new work to that batch before uploading. We should recommend to a transcriber that if they are returning to work on a batch, to first check if the batch is locked and if it is to download it.

[edickens]

I like Kirk's idea of calling them a Soft and Hard lock. I think this describes the purpose of these locks much better. The Soft lock is through editing. The Hard lock is deliberately set by someone with the authority to do so. But again, as Kirk said, the Hard lock is very rare and we should not get worked up about it. The present system has worked for three years to prevent transcribers overwriting the online edits, the most important reason for a lock.

[SteveBiggs]

EricD wrote: "My understanding is that when doing any online Edit, only the Transcriber Lock is set. Downloading does, for the reasons Steve says, then removes this lock. The Coordinator Lock is much harder and prevents the batch from being amended in any way until it is unlocked. It has to be set by a CC and is not set by just making a correction."

Your understanding is wrong Eric. As I explained earlier in this story, currently the coordinator and transcriber locks work in exactly the same way and are both 'soft'. If I as CC/SC make an edit to a transcriber's file, the CC/SC lock is set, but the transcriber can still download the file and unset the CC/SC lock just as they can unset the transcriber lock. This was done by design and I have verified it using my different IDs.

[edickens]

Perhaps I should have that was the way I thought it would work when it was designed. I don't use the locks. Is it time for a debate and revision in V1.6?

[SteveBiggs]

We could change the names to 'Hard' and 'Soft' lock. The Soft lock being set when either the transcriber or coord edits an entry. The Hard lock being settable only by a coord (or higher) in order to stop any further edits until a coord unlocks it - but this would need to be used only in special circumstances .....

[edickens]

It may require a little extra coding. If the Hard lock is set by the CC, the Soft should also be set. I think the uploading of a batch already checks for the Soft lock, so no change needed if both locks are set by the CC. The download needs to check if the Hard lock is set, and if so, not to allow the download but to provide the message "Hard locked, please contact your Coordinator".

[SteveBiggs]

Since it's been another 5 years since this discussion, a decision is needed - do we forget it or assign it to a programmer?