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.
More observable based, more scaleable filtering
based on an old branch of @FinnStutzenstein.
cleans some functions and provides some differend features.
Calculates the direction of the moving.
Finishes the moving of nodes in same level
Adds some style
Sets the padding dynamically
Adds placeholder depends on the horizontal movement
Set the placeholder at the correct place, so the user can see, where he will drop the moved node
Finishes moving of nodes
- Old parents change their option to expand.
- New parents change their option to expand.
- If the user moves a node between nodes with a higher level, the node will be moved to the next index with same or lower level.
Fixes the visibility of moved node
- If the new parent is not visible, the moved node will not be seen.
If the user moves an expanded node, the new parent should expanded, too, if it's not already.
Sending successfully data to the server
- Sorting the items
Handles moving nodes between parent and children
- If the user moves a node between a parent and its children, the children will be relinked to the moved node as their new parent.
Replaces the old `sorting-tree` to a new one
- The new `sorted-tree` replaces the old `sorting-tree`.
- The old package `angular-tree-component` was removed.
- The user will only see the buttons to save or cancel his changes, if he made changes.
- The buttons, that do not work currently, were removed.
Adds a guard to check if the user made changes.
- If the user made changes but he has not saved them, then there is a dialog that will prompt to ask for confirmation.
Before cancelling the changes the user has to confirm this.
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.
