Assigns the weight in the preorder traversal of the tree. Now one without every
object (e.g. missing motions/items) still have the correct sorting. Intorduces
the level attribute of items giving the amount of parents in the agenda. This
allows to reduce complexits in the client.
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.
* 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
The old hidden type was used as internal, so everything is changed to
not be shown if the item is internal. hidden is "new", and actually
behaves as hidden now.
* 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.
- Used raw SQL for createing default projector during inital migration.
- Removed default_password and hidden agenda items from autoupdate data for some users.
- Removed old get_collection_and_id_from_url() function.
