This fixes a bug where a saved filter would contain many "dead" entries for tasks which are not part of that filter. These entries were "dead" because the filter would not match for them and thus they were not shown.
The problem was caused by a routine during the creation of the filter where all projects from all matching tasks would be used as input for fetching the tasks to add to task_positions.
https://community.vikunja.io/t/not-able-to-move-task-between-buckets-within-a-kanban-view-for-saved-filter/2882/3
If a task is overdue at the same time the notification is sent, it would contain a message like "overdue since" without a time. This now shows "overdue now" instead.
Currently vikunja has a `/health` endpoint that was added in https://kolaente.dev/vikunja/vikunja/pulls/998. Docker/compose cannot utilize this feature since vikunja's docker image doesn't have curl/wget as it is pruned which is great for the image size. This PR adds a `healthcheck` command that send an http request to `/health` and exits with 0 or non-zero depending on the result.
It also adds a `HEALTHCHECK` to the docker image which calls this automatically.
Reviewed-on: https://kolaente.dev/vikunja/vikunja/pulls/2856
Reviewed-by: konrad <k@knt.li>
Co-authored-by: ScribblerCoder <omar2001.oh@gmail.com>
Co-committed-by: ScribblerCoder <omar2001.oh@gmail.com>
Closes [#348](https://github.com/go-vikunja/vikunja/issues/348)
When moving a project, the old task bucket entries (project, saved
filters) will be removed, but not the corresponding position. This has
the effect that the saved_filter event hook UpdateTaskInSavedFilterViews
wrongly assumes that the task doesn't need to be re-added to the saved
filter since the position part still exists.
Reviewed-on: https://kolaente.dev/vikunja/vikunja/pulls/2840
Co-authored-by: Maximilian Bosch <maximilian@mbosch.me>
Co-committed-by: Maximilian Bosch <maximilian@mbosch.me>
The config values for openid providers now use a map with the provider as key instead of an array. For example before:
auth:
openid:
providers:
- name: foo
clientid: ...
now becomes:
auth:
openid:
providers:
foo:
clientid: ...
This allows us to read values for openid providers from files using the same syntax as everywhere and makes the configuration more predictable. It also allows configuring providers through env variables, though it is still required to set at least one value via the config file because Vikunja won't discover the provider otherwise.
This removes reading config values from _file and instead only reads from file sub keys. This should make it easier to not accidentally specify the same value twice.
The syntax via env does not change, but via a config file this:
database:
password_file: foo
becomes
database:
password:
file: foo
This change allows to read any config value from a file, when the path to that file is specified in the config with the target config value suffixed with _file. This works with environment variables as well.
For example, setting database.password_file=/path/to/password will load the value from /path/to/password and set it as the config value of database.password.
Resolves https://kolaente.dev/vikunja/vikunja/issues/704
Resolves https://kolaente.dev/vikunja/vikunja/pulls/1621
Fetching the task comments during indexing would always check the permissions - in the specific case of indexing comments into Typesense, this will always return true, because we're checking with the owner of the project. Because this is a rather expensive operation, it is even more unnecessary.
The removal of the unnecessary join condition speeds up the query 10x. Before, it would take ~700ms on Vikunja Cloud. With this removal, the otherwise same query now takes ~70ms (which still leaves plenty of room for improvements, but it's already a great step forwards).
This adds a feature where you can enable users to only find members of teams they're part of. This makes the user search when sharing projects less confusing, because users only see other users they already know.
It is still possible to add users to teams with their email address, if they have that enabled in the user settings.
When running the testmail command, Vikunja would not stop if it wasn't able to connect to the mail server. This was a regression from 950de7c954.
This change fixes that problem.
Resolves https://kolaente.dev/vikunja/vikunja/issues/2767
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 commit introduces the automatic retrieval of TLS certificates from Let's Encrypt. If the feature is enabled, Vikunja will automagically request a certificate from Let's Encrypt and configure it to server content via TLS.
This PR introduces a partial fix for the CalDAV task listing bug (#753) when handling PROPFIND requests with `Depth: 1`, improving task visibility in the iOS Reminders app.
Notes:
* This might make Thunderbird somewhat usable when interacting with tasks using the `/dav/projects/{id} url`.
* This does not fully resolve the issue where the Reminders app will only display the last project after some time when adding the URL.
This is my first time working with Golang and CalDAV, so I’d really appreciate any feedback or suggestions on the code structure, style, or any improvements I could make.
Co-authored-by: JD <43763092+jdw1023@users.noreply.github.com>
Reviewed-on: https://kolaente.dev/vikunja/vikunja/pulls/2717
Reviewed-by: konrad <k@knt.li>
Co-authored-by: jd <jd@noreply.kolaente.dev>
Co-committed-by: jd <jd@noreply.kolaente.dev>
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
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/
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
When creating a related task during the import, migrating would fail because the migration would try to add the task to a bucket before the task was created. This fix changes the order in which that happens to prevent the error.
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.
This makes the Trello migrator include attachments that are not file uploads. To include them in Vikunja without missing data, their text (usually links) will be appended to the Vikunja description.
Co-authored-by: Elscrux <nickposer2102@gmail.com>
Reviewed-on: https://kolaente.dev/vikunja/vikunja/pulls/2261
Reviewed-by: konrad <k@knt.li>
Co-authored-by: Elscrux <elscrux@gmail.com>
Co-committed-by: Elscrux <elscrux@gmail.com>
This change introduces notifications via mail when a migration fails. It will contain the error message and a hint to post it in the forum when Sentry is disabled, otherwise the error message will be sent directly to sentry and the notification will inform accordingly.
I've tried to balance "this thing failed, go figure it out" with "here is what we know and how you can get help", we'll see how well that approach works.
kolaente
graves501
ScribblerCoder
Frederick [Bot]
Maximilian Bosch
John Doe
Sterad
jd
Dominik Pschenitschni
Elscrux
Balázs Keresztury