This change introduces an expand query parameter which, when provided, allows to return all projects with the max right the current user has on that project. This allows to show and hide appropriate buttons in the frontend.
Resolves https://github.com/go-vikunja/vikunja/issues/334
This allows to configure the used bcrypt rounds and set it to 4 in tests, greatly speeding up the tests. It's not really required to set this to another value but it might be in the future as computers get faster.
This fixes two closely-related bugs:
1. When loading tasks from a bucket of a saved filter, the saved filter query would override the user-supplied filter, which would cause to only tasks matching the saved filter query to be returned.
2. When a filter query for a bucket was specified, the function would only check if one of the top level filters was a filter for tasks in a specific bucket. That means a filter like "bucket_id = 42 && labels = foo" would return the expected result, while a filter like "labels = foo && (bucket_id = 42 && priority = 1)" would fail with an error 500 because the task_buckets table was not joined to the sql query. The fix from the first bug caused such filter queries.
Mysql cannot handle year values < 1. That means filtering for a date value like 0000-01-01 won't work with mysql. Additionally, dates like 0001-01-01 could under some circumstances not work either when the date in combination with the time zone would resolve to something like 0000-12-31 - for example when the server is located (and configured) in UTC, but the user running the query is in New York. This could be observed by setting the time zone manually using the filter_timezone query parameter.
Resolves https://vikunja.sentry.io/share/issue/42bce92c15354c109eb1e6488b6a542b/
Resolves https://vikunja.sentry.io/share/issue/ef81451b0c7b43f1bff2d3a86ba393bb/
This fixes an issue where it would be impossible to update a task in Typesense when the position for a view of it was previously saved as int64. This happened because the field is created per view on demand and its type is automatically inferred from the data saved. Now, when the first value for a particular position field is a float which could as well be an int (for example, 42.0), that field gets created as an int64 instead of float. Subsequent tries to save a float into that field will then fail.
Additionally, errors about this are silently discarded when using bulk insert. That's why the problem was not really debuggable at first.
Whenever a task is part of a date filter, it might fall in or out of a filter bucket without anything changing, other than the current time. For example, a filter condition like due_date > now may include different tasks depending on the current time.
For these kinds of tasks to properly show up in the kanban view of a filter, there has to be an entry in the task_buckets table. These entries only got updated when either a task was updated or the filter itself was updated. To account for th changing of time, we also need to check periodically if tasks are now part or not anymore part of that filter.
This change adds a cron task to do precisely that.
We'll have to see if this works resource-wise, but the cron is not the only one doing a bunch of sql queries so it might be fine after all.
Resolves https://community.vikunja.io/t/tasks-in-saved-filter-appear-in-list-view-but-are-not-visible-in-kanban-view/2800
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
Vikunja now uses one recursive CTE and a few optimizations to fetch all subscribers for a task or project. This makes the relevant code easier to maintain and more performant.
Before this fix, a project subscription object was added twice to the list of subscriptions for a task when the user did not subscribe to the task directly. This caused the user to receive a comment notification twice for a given task.
This was probably a regression from efde364224.
Resolves https://community.vikunja.io/t/e-mail-notification-twice/2740/18
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
This fixes a bug where values would not be trimmed before parsing them. That resulted in a value like " 2" being invalid, even though it's a perfectly fine number.
Because the frontend sends the filters for projects and other values with comma-separated spaces like "1, 2, 3", this essentially broke filtering by these values.
Resolves https://kolaente.dev/vikunja/vikunja/issues/2547
Before this fix, creating a project with Typesense enabled would fail with an error because the tasks it fetches as part of that process do not have the task position property in their index. We now fall back to using the db for searching in that case.
In the long run, we should use typesense joins for the task position to make this more efficient.
BREAKING CHANGE: The bucket id of the task model is now only used internally and will not trigger a change in buckets when updating the task.
This resolves a problem where the task update routine needs to know the view context it is in. Because that's not really what it should be used for, the extra endpoint takes all required parameters and handles the complexity of actually updating the bucket.
This fixes a bug where it was impossible to move a task around between buckets of a saved filter view. In that case, the view of the bucket and the project the task was in would be different, hence the update failed.
Previously, the bulk api endpoint were explicitly filtered out. This meant that you couldn't use them with api tokens.
This change adds them to their "parent" token types as another option, allowing users to select and use them when creating api tokens.
Resolves https://community.vikunja.io/t/help-with-bulk-api-complete/2461
This change fixes a bug where adding or removing an assignee to a task would not update the index in Typesense, causing filter queries for that assignee to return incorrect data. This was caused by the events being dispatched by the task update process not containing all the data.
Resolves https://github.com/go-vikunja/vikunja/issues/255
This change fixes a bug where Typesense would try to sort by the project view of a saved filter. The view position is not indexed in Typesense, hence filtering fails. Because sorting by position is not a feature in saved filters, I've removed the logic for sorting saved filters with Typesense.
This change fixes a bug where the project view to use for joining was empty, since Typesense only supports 3 sorting parameters. When using more than that, the logic to fetch the view ID parameter would not return the correct parameter, but the logic building the order by statement would. That led to inconsistencies where the task position was included in the order by statement, but the table would not be joined, failing the query.
Previously, only routes which were coming from crudable entities could be used with an api token because there was no way to assign permissions to them. This change implements a more flexible structure for api permissions under the hood, allowing to add permissions for these routes and making them usable with an api token.
Resolves https://github.com/go-vikunja/vikunja/issues/266
This fixes a bug where the current number of tasks in a bucket was computed wrong when moving tasks into a bucket with a limit. Sometimes the bug would prevent adding a task to a bucket which seemed to have space left but ultimately failed when moving the task.
Previously, in a filter like "due_date = now/d", the / was parsed as the beginning of a comment, but as it did not contain the full value, this is an invalid comment, resulting in an error message.
Resolves https://community.vikunja.io/t/filter-setting-s/1791/12
When a new project was created, it contained all details already. This led to duplicated views and overridden attributes in the response.
Resolves https://kolaente.dev/vikunja/vikunja/issues/2242
Sterad
kolaente
Dominik Pschenitschni
Elscrux
waza-ari