The very first task in a bucket always has the position 0. Now, if we move another task in front of that, it too gets the position 0 assigned. That means the two first tasks now both have the position 0 and are not sorted correctly. This commit fixes that: When moving a task to the very first position it checks if the task now on the second position also has position 0 assigned to it. If that's the case, we'll now update that task's position as well to make sure it has another position than 0.
This replaces links with BaseButton components. BaseButton will use `<button type="button">` inside for this case. This improves accessibility a lot. Also we might be able to remove the `.stop` modifiers in some places because AFAIK the button element stops propagation by default.
Probably caused by the blur hash feature, switching between lists would not work if the list background was set via unsplash. I've refactored the whole decision tree which checks if a background should be loaded or not. It actually does not matter where the background is from (unsplash or upload) or if we had one in the last list - we only need to know if the current list has a background or if we just changed it and need to update right away.
To make sure the tasks of a list are only loaded after the list itself is fetched from the server, we hide the list view until the list is fully loaded. When switching between different views of the same list, this would cause the list view to not be loaded at all because the list was already loaded at that point.
closes#1732
The new list background was set on the home page when navigating to the list. This was because the `CURRENT_LIST` was set to the last visited list, even after the call to `this.$store.commit(CURRENT_LIST, null)` because everything is async. I tracked the problem down to the call to `watchEffect` in the ListWrapper component. Apparently, `watchEffect` is called every time _the watched variable is assigned to_ and not only when it changes. When navigating away from the list, that watcher is getting called with the list id, the one already loaded, and sets it in store which in turn overrides the call from the contentAuth component.
When creating a new list, setting a background and then navigating to the home page, the list background would not be shown in the list card. Now, we're setting the newly updated list with all its background information properly in store (why are there even multiple places for this?).
Currently, when opening a list sometimes the tasks are shown before the list itself is loaded. Because the list contains the rights, this means no edit buttons etc are available at that point which is pretty confusing.
This PR ensures the list-specific view is loaded only after the list itself is loaded.
Co-authored-by: kolaente <k@knt.li>
Reviewed-on: #1251
