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
* 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
* Second websocket channel for the projector
* Removed use of projector requirements for REST API requests.
Refactored data serializing for projector websocket connection.
* Refactor the way that the projector autoupdate get its data.
* Fixed missing assignment slide title for hidden items.
* Release all items for item list slide and list of speakers slide. Fixed error with motion workflow.
* Created CollectionElement class which helps to handle autoupdate.
Uses django channels instead of tornado for the autoupdate. Therefore
tornado is nolonger a dependency of OpenSlides (but channels).
This uses websockets instead of SockJS.
Use the flag insecure in the start command to provide static files serving.
Use a new session backend that has a ForeignKey to User.
FinnStutzenstein