- Added settings.py docs
- Fixed left-overs from #4920
- Reworked all server messages to a new argument formet, so that the
client can translate server messages
- 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
- Moved projector configs to group "General"
- Removed unused projector config related to CLOS
- debounce projector data requests for many projectors
- add (foreground) color
- custom, modifiable CSS classes per projector to cascade dynamic styles into slides
Server:
- ListOfSpeakers (LOS) is now a speprate model, containing of an id,
speakers, closed and a content_object.
- Moved all speaker related views from ItemViewSet to the new
ListOfSpeakersViewSet.
- Make Mixins for content objects of items and lists of speakers.
- Migrations: Move the lists of speakers from items to the LOS model.
Client:
- Removed the speaker repo and moved functionality to the new
ListOfSpeakersRepositoryService.
- Splitted base classes for agenda item content objects to items and
LOS.
- CurrentAgendaItemService -> CurrentListOfSpeakersSerivce
- Cleaned up the list of speakers component.
- If the previously selected theme is not available the default OpenSlides theme will be displayed.
- Before the current selected theme was loaded, no theme is displayed.
Introdcues a new update service.
Listens to service-worker updates and shows a snack-bar to inform about updates.
Provides a function to manually check for updates.
The service worker tries to be consistent in it's own version and
updates in the background.
Some manuall trigger will be required to update, which is either a
reload or the execution of the provded check function
with help from
@FinnStutzenstein
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.
