This change allows to specify the task index when creating a task, which will then be checked to avoid duplicates and used. This allows us to calculate the indexes for all tasks beforehand when creating them at once using quick add magic.
The method is not bulletproof, but already fixes a problem where multiple tasks would have the same index when created that way.
Resolves https://community.vikunja.io/t/add-multiple-tasks-at-once/333/16
(cherry picked from commit 55dd7d2981)
Bcrypt allows a maximum of 72 bytes. This is part of the algorithm and not something we could change in Vikunja. The solution here was to restrict the password during registration to a max length of 72 bytes. In the future, this should be changed to hash passwords with sha512 or similar before hashing them with bcrypt. Because they should also be salted in that case and the added complexity during the migration phase, this was not implemented yet.
The change in this commit only improves the error handling to return an input error instead of a server error when the user enters a password > 72 bytes.
Resolves https://vikunja.sentry.io/share/issue/e8e0b64612d84504942feee002ac498a/
(cherry picked from commit 44a43b9f86)
This fixes a bug where the position of a task would not be calculated correctly when the task was moved next to another recently moved task. The problem was caused by the calculation of the new position referring to the old value of the position attribute, because it was not updated in the local store.
Resolves https://community.vikunja.io/t/kanban-cards-in-wrong-order/2731/6
(cherry picked from commit 22e594e253)
Previously these store methods created multiple edits on deep objects in the store or edited a deep nested object directly.
This is bad because:
- multiple edits lead to multiple triggers of all the watchers on the project.
- in theory we should listen deep to a project if we use some deep reactive value of a project, if we want deep updates. Because this is easy to forget, it's better to update the project directly. For this the method `setProject` already existed in the store. This is no real overhead because Vue is smart enough to only trigger listeners that use data of the modified state.
By modifying only a copy of the view and submitting the modified result __once__ we can save us a lot of headache.
PS: I'm not sure if there were any visible problems, because Vue is really fast and the reactivity system works quite well. Regardless of this we should try not to modify state unnecessarily.
(cherry picked from commit 1e632397d2)
This fixes a UI issue where if a user had a filter set and marked the task done, it would not disappear, even though the filter does not match the done task anymore.
kolaente
Frederick [Bot]andkolaente
Dominik Pschenitschniandkolaente