SORMAS-Project

SORMAS-Project copied to clipboard

Feature Description

In order to ensure that errors do not occur during simultaneous processing of a share, it must be ensured that a data record is blocked for processing by other persons.

For this purpose, a new mechanism is introduced which can be extended to other places in SORMAS at a later date.

A new table will be introduced in the database that contains information about locked records. It is called "DataLocks" and is structured as follows:

Name	Type	Description
GUID_Data	VARCHAR(200)	GUID of the locked data set
GUID_LockedBy	VARCHAR(200)	GUID of the user by whom the record is locked
LockedAt	TIMESTAMP	The time (server time) at which the record was locked.

Proposed Change

Opening test

If a user opens a record, the system checks whether the record is available for editing and locks it if necessary.

This is done according to the following principle:

1. Reading the entry for the GUID of the record to be opened from the table "DataLocks".

a. data set exists

i. Check whether the value "GUID_LockedBy" corresponds to the user currently logged in.

1. yes

a. The record can be edited as usual.

2. no

a. Check if the value "LockedAt" is more than 30 minutes in the past (reference is the time zone of the server, not the localised time zone of the user (question: so if a user take lunch break and forgets to close the record the user who wants to add something has to wait 30 minutes?)

i. yes

1. Overwrite the entry in the table "LockedAt" with the current timestamp and the GUID of the currently logged in user. (question if the user before added something but did not save the information will be lost?)
2. The record can be edited as usual.
   

ii. No

1. The record can only be viewed but not edited (all fields are greyed out and a corresponding message appears) (question: at least we should implement that the blocking user is named by name so one can contact this user by writing a task, mail or phone to hurry up, or even better: the user who can not write can click on a button and then the user who is blocking gets a pop-up window "User first name last name wants to edit this record" and has to close the window before continue writing)
   

b. no data set exists

i. Create a record in the table "DataLocks" for the current record, the GUID of the currently logged in user and the current timestamp of the server.
ii. The data set can be edited as usual.

Overwriting the lock after 30 minutes is a failsafe to ensure that data records do not remain in a locked state due to an error in the system and cannot be released again.

In the medium term, the time should be made configurable on the server and administrators should be given the possibility to see and manually release locked records. (should be implemented at the beginning. If we implement this the health departments will like this feature, if not i am not sure about this)

check during saving

To ensure that the lock on the data set has not been taken over by the failsafe of another user in the meantime, a further check must be carried out before saving.

1. Reading the entry for the GUID of the data set to be saved from the "DataLocks" table

a. data set exists

i. Check whether the value "GUID_LockedBy" corresponds to the user currently logged in.

1. yes

a. It can be saved

2. No

a. It must not be saved. Log the error in the server log and display a corresponding error message. (For the error message, another query is necessary for the user's first name, last name).

b. no record exists

i. This should theoretically never happen, but since no lock exists, it can still be saved.

check during closing

If the window for editing the data set is closed (whether after saving or by cancelling), the lock on the data set may have to be released.

1. Reading the entry for the GUID of the data set to be saved from the "DataLocks" table

a. data set exists

i. Check whether the value "GUID_LockedBy" corresponds to the user currently logged in.

1. yes

a. Delete the entry for the GUID of the data set from the "DataLocks"

2. no

a. Do not make any changes to the table "DataLocks"

b. no record exists

i. In theory, this should never happen. However, in this case nothing has to be executed.

Acceptance Criteria

Implementation Details

Localisation

value	de_DE	Default
Error message when trying to save a locked record	This record is locked by First Name Last Name and could not be saved.	Unabel to save. Entity is locked by user FirstName LastName.

Additional Information

@JaquM-HZI

IIRC from a technical perspective, there are ways using compare-and-swap to lock tables, not certain if we should build something on our own here instead of relying on DB features...

Similar to https://github.com/hzi-braunschweig/SORMAS-Project/issues/3985 and https://github.com/hzi-braunschweig/SORMAS-Project/issues/2647. Revise discussions or approaches there and discard issues which are not favoured over others.

Just some comments:

• "Locked" could be misleading since it doesn't imply whether or when a dataset could become unlocked. Instead, we could simply speak of "currently edited by username" or "currently being worked on by username".
• If we want to make it easier for users to know which datasets are being worked on, we could display this via an icon per row on the directory. While hovering, it could display the text mentioned above > This could easily be a follow-up issue though