Skip to content
GitLab
Menu
Projects
Groups
Snippets
Loading...
Help
Help
Support
Community forum
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in
Toggle navigation
Menu
Open sidebar
typo3
qfq
Commits
3328b8ca
Commit
3328b8ca
authored
Dec 20, 2019
by
Carsten Rose
Browse files
Merge remote-tracking branch 'origin/master'
parents
01647bbc
1f3f1df6
Pipeline
#3092
passed with stages
in 1 minute and 48 seconds
Changes
1
Pipelines
1
Hide whitespace changes
Inline
Side-by-side
Documentation-develop/PROTOCOL.md
View file @
3328b8ca
...
...
@@ -484,9 +484,6 @@ Server Response
### 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).
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
and needs to pass back to dirty.php as well.
...
...
@@ -500,7 +497,6 @@ URL Parameters
:
`s=<SIP>`
(form, r)
:
`action=lock`
,
`action=extend`
,
`action=release>`
:
`recordHashMd5=<value of hidden form element 'recordHashMd5'>`
:
`tabUniqId=<unique id>`
Server Response
: The response contains an [Lock Response].
...
...
@@ -513,7 +509,7 @@ JSON Response from the server (extended [Minimal Response]) containing:
: {
: "status": "success"|"error"|"conflict"|"conflict_allow_force",
: "message": "
<message>
"e5
: }
:
}
`status`
indicates how the request has been fulfilled by the server.
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).
### tabUniqId
*
Client: Every browser tab get's a
`tabUniqId`
(timestamp) as soon as the first time a lock is requested (acquire).
This
`tabUniqId`
remains, until the tab is close. It is saved in window.name.
*
Server: On lock request, the
`tabUniqId`
is saved in dirty record.
*
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.
Every tab get's a uniq id (timestamp) on page load: 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
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.
### Drag And Drop (sort)
...
...
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
.
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment