Commit 3328b8ca authored by Carsten  Rose's avatar Carsten Rose
Browse files

Merge remote-tracking branch 'origin/master'

parents 01647bbc 1f3f1df6
Pipeline #3092 passed with stages
in 1 minute and 48 seconds
...@@ -484,9 +484,6 @@ Server Response ...@@ -484,9 +484,6 @@ Server Response
### Record lock ### Record lock
Request, extend or release a lock for a record, identified by the SIP. The SIP contain a SIP_FORM and a SIP_R (record id). Request, extend or release a lock for a record, identified by the SIP. The SIP contain a SIP_FORM and a SIP_R (record id).
See `Documentation-develop/diagram` for a state diagram.
To detect record change at time of 'record lock' or 'record save', a MD5 hash is provided from the server To detect record change at time of 'record lock' or 'record save', a MD5 hash is provided from the server
and needs to pass back to dirty.php as well. and needs to pass back to dirty.php as well.
...@@ -500,7 +497,6 @@ URL Parameters ...@@ -500,7 +497,6 @@ URL Parameters
: `s=<SIP>` (form, r) : `s=<SIP>` (form, r)
: `action=lock`, `action=extend`, `action=release>` : `action=lock`, `action=extend`, `action=release>`
: `recordHashMd5=<value of hidden form element 'recordHashMd5'>` : `recordHashMd5=<value of hidden form element 'recordHashMd5'>`
: `tabUniqId=<unique id>`
Server Response Server Response
: The response contains an [Lock Response]. : The response contains an [Lock Response].
...@@ -513,7 +509,7 @@ JSON Response from the server (extended [Minimal Response]) containing: ...@@ -513,7 +509,7 @@ JSON Response from the server (extended [Minimal Response]) containing:
: { : {
: "status": "success"|"error"|"conflict"|"conflict_allow_force", : "status": "success"|"error"|"conflict"|"conflict_allow_force",
: "message": "<message>"e5 : "message": "<message>"e5
: } : }
`status` indicates how the request has been fulfilled by the server. `status` indicates how the request has been fulfilled by the server.
On`"success"`, the Client display nothing to the user. On`"success"`, the Client display nothing to the user.
...@@ -524,18 +520,11 @@ On `"conflict_allow_force"` the Client opens the alert non-modal (default). ...@@ -524,18 +520,11 @@ On `"conflict_allow_force"` the Client opens the alert non-modal (default).
### tabUniqId ### tabUniqId
* Client: Every browser tab get's a `tabUniqId` (timestamp) as soon as the first time a lock is requested (acquire). Every tab get's a uniq id (timestamp) on page load: window.name.
This `tabUniqId` remains, until the tab is close. It is saved in window.name. This 'tabUniqId' is saved in dirty record on lock acquire.
On page reload, when the 'release' comes after 'acquire' (unwished async behaviour), the locking is skipped (if same user
* Server: On lock request, the `tabUniqId` is saved in dirty record. session) - on reload there is no variable 'tabUniqId'. On real lock acquire, the tab ID is compared and will be denied
if not matching. The 'tabUniqId' might not work in IE - doesn't matter: it's a seldom special situation.
* The `tabUniqId` helps to implement 'optimistic locking': if there is no argument against 'grant lock' - grant it.
Example: In browser tab 'A' a lock is requested. For unknown reason, there is a stale lock for the
user session and the given tab id: grant the log.
* Unexpected async behaviour in client: On page reload (F5), the 'lock release' might come after 'lock acquire'.
The form goes in 'read only' mode - an additional page reload (F5) solves the situation - but this is boring.
### Drag And Drop (sort) ### Drag And Drop (sort)
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment