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 #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: #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 #704
Resolves #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.
This PR introduce a new config for database, `database.schema`, allowing user to specify a specific schema to use for their postgres database connection. As the default value is set, it will be backward compatible.
Related discussion: https://community.vikunja.io/t/postgres-database-has-error-pq-relation-tasks-does-not-exist/1333
Reviewed-on: #2777
Co-authored-by: John Doe <hugosum.dev@protonmail.com>
Co-committed-by: John Doe <hugosum.dev@protonmail.com>
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 950de7c954ef3799051d73bc9b728558cf166377.
This change fixes that problem.
Resolves #2767