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 55dd7d298187dcc8393ae67340117d66d45dc4ef)
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 1e632397d29e9d45609b9271e00111c0a6cb2c57)
This fixes a bug where tasks which had their done status changed were not moved in the correct bucket. This affected both frontend and api. The move of the task between buckets is now correctly done in the api and frontend - with a bit of duplicated logic between the two. This could be optimized further in the future.
Resolves https://kolaente.dev/vikunja/vikunja/issues/2610
Originally, it was possible to specify repeating intervals for months or years. This was actually misleading because the interval would be converted to seconds under the hood, causing all kinds of problems with leap years and months with 30 vs 31 days. Because of that, the options for month and year were removed in 7746d3916157e43fca7a24e2a768f7fb83136cf1 to make it clear what these actually meant.
Now, since we do have a repeating mode "Monthly", this commit changes the behaviour to repeat a task monthly when it was specified as "every month", but only that. All other cases were removed from the docs since they are not actually supported.
https://github.com/go-vikunja/vikunja/issues/271
When the demo mode is enabled, people set the language to their own language - which is understandable. However, this is really confusing for other people when they log in and the language is something unexpected.
This change overrides the configured language when saving it while Vikunja is in demo mode.
This PR adds reactions for tasks and comments, similar to what you can do on Gitea, GitHub, Slack and plenty of other tools.
Reviewed-on: https://kolaente.dev/vikunja/vikunja/pulls/2196
Co-authored-by: kolaente <k@knt.li>
Co-committed-by: kolaente <k@knt.li>
Previously, when creating a filter query with the 'in' operator and multiple values, autocompletion and highlighting was not available. This change now implements a split for each value, seperated by a comma.
Before this change, applying a filter and then scrolling a bucket would not use that filter when lazy loading the tasks in that bucket. That resulted in all tasks being loaded, regardless if the filter applied to them.
