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.
- Removed the restricted data cache (it wasn't used since OS 3.0)
- unify functions for restricted and full data: Just one function, which
accteps an optional user_id: If it is None, full data is returned, and
with a user id given, the restricted data
- More atomic access to redis, especially for:
- Check for data-existance in redis and do an auto-ensure-cache.
- Speedup through hashing of scripts and redis' script cache.
- Save schema version into the redis cache and rebuild, if the version
changed
Client changes:
- Simplified the ConstantsService
- Fixed bug, when receiving an autoupdate with all_data=True from the
Server
Before this commit, there where two different locks when updating the restricted
data cache. A future lock, what is faster but only works in the same thread. The
other lock is in redis, it is not so fast, but also works in many threads.
The future lock was buggy, because on a second call of update_restricted_data
the same future was reused. So on the second run, the future was already done.
I don't see any way to delete. The last client would have to delete it, but there
is no way to find out which client the last one is.
* Activate restricted_data_cache on inmemory cache
* Use ElementCache in rest-api get requests
* Get requests on the restapi return 404 when the user has no permission
* Added async function for has_perm and in_some_groups
* changed Cachable.get_restricted_data to be an ansync function
* rewrote required_user_system
* changed default implementation of access_permission.check_permission to
check a given permission or check if anonymous is enabled
* geis does not work with channels2 and never will be (it has to be python now)
* pytest
* rewrote cache system
* use username instead of pk for admin user in tests
* change get_restricted_data and get_projector_data to always use a list
* Add typings to all get_restricted_data and get_projector_data methods
* Replace CollectionElementList with a real list
* Fixed arguments of inform_deleted_data
* Moved CollectionElementCache to cache.py and refactored it
* Run tests with cache enabled (using fakeredis)
* Add caching support to users/group
* Add a function has_perm that works with the cache.
* Removed our session backend so other session backends (without the database) can be used
Also added the derective osPerms to check if the current user has permissions.
Removed old Django views and urls for user.
Created utils.views.APIView which should be used instead of the AjaxView.
Fixes: #1470Fixes: #1454
* seperate unittests and integration tests
* moved old tests in seperat folder 'old'
* created a testrunner that does not create a testdatabase, if only unittests are run
* wrote some unit- and integration tests as examples
* fixed user.get_short_name() to use the sort order from config
* fixed wrong url_pattern in the user app
