Recent changes to amendment had various bugs.
This one regarded the amendment list, where amendments without amendmend
paragraphs returned several errors.
Replace the external link button with a (real) Dialog containing the
jitsi iFrame.
The dialog can be hidden but not entirly closed.
Replace all dialogService.closeAll() functions by closing the specific
dialog rather than all of them.
A conceptional issue in `get_data_since` leads to incomplete
autoupdates. The behaviour was long time in the code, but only with a
lot of autoupdates (high concurrency) and the autoupdate delay I noticed
the bug during testing. I'm sure, that this issue might have caused
incomplete autoupdates (which the user may experience as "lost
autoupdates") in previous productive instances. Instead of quering a
range (from_change_id to to_change_id) one now can only get data from a
change id up to the max change id in the element cache. The max change
id gets now returned by `get_data_since`.
I also added a get_all_data with the capability of returning the
max_change_id at this point of time.
As a usability-"fix" (more like a fix the result of a bug, not the bug
itself) a refresh button for a poll was added, that issues an autoupdate
for the poll and all options.
- Extracted autoupdate code from consumers
- collect autoupdates until a AUTOUPDATE_DELAY is reached (since the first autoupdate)
- Added the AUTOUPDATE_DELAY parameter in the settings.py
- moved some autoupdate code to utils/autoupdate
- moved core/websocket to utils/websocket_client_messages
- add the autoupdate in the response (there are some todos left)
- do not send autoupdates on error (4xx, 5xx)
- the client blindly injects the autoupdate in the response
- removed the unused autoupdate on/off feature
- the clients sends now the maxChangeId (instead of maxChangeId+1) on connection
- the server accepts this.
If autoupdates are too fast, the first one may not be fully executed. Especially when the maxChangeId is not yet updated, the second Autoupdate will trigger a refresh, because for the client it "lay in the future". This can be prevented by synchronizing the autoupdate-handling code with a mutex.
if the default cr mode is 'original' nothing really happens
if the default cr mode is 'changed' you will stay in original view after
creating cr's. That's due to the autoupdate limitation. Changing this
would mean that you cannot change the view anymore
if the default cd mode is 'diff' you will switch to diff view after
creating a cr. It seems that the diff view has an automatic fallback to
the original view if no cr exists, perhaps Tobias knows more about that.
If the default cr mode if 'final' you will try to change to
mod-final-version if it exists. If there is no change-reco, you will
fall back to original version.
