When the tasks were migrated from belonging directly to a bucket to only belonging to a view, I forgot to add the view in that migration, resulting in task buckets where the view was 0. These entries were not deleted when a task was moved between buckets, but the new task bucket relation nevertheless inserted. This resulted in tasks showing up multiple times on the kanban board.
This change adds a new migration which adds the correct project view id (as derived from the bucket) and fixes the old migration as well.
Resolves https://community.vikunja.io/t/no-longer-able-to-properly-move-tasks-between-kanban-columns/2175
BREAKING CHANGE: the position of tasks now can't be updated anymore via the task update endpoint. Instead, there is a new endpoint which takes the project view into account as well.
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: #2196
Co-authored-by: kolaente <k@knt.li>
Co-committed-by: kolaente <k@knt.li>
The change introduced in #2150 introduces a bug where a Team would be re-created every time a user logs in, as the check if a team already exists was based on both the unique `oidcID` and the `name`. This PR proposes to only base the check on the ID, as this should be unique.
Co-authored-by: Daniel Herrmann <daniel.herrmann1@gmail.com>
Reviewed-on: #2152
Reviewed-by: konrad <k@knt.li>
Co-authored-by: waza-ari <daniel.herrmann@makerspace-darmstadt.de>
Co-committed-by: waza-ari <daniel.herrmann@makerspace-darmstadt.de>
This change adds the ability to sync teams via a custom openid claim. Vikunja will automatically create and delete teams as necessary, it will also add and remove users when they log in. These teams are fully managed by Vikunja and cannot be updated by a user.
Co-authored-by: kolaente <k@knt.li>
Reviewed-on: #1393
Resolves #1279
Resolves https://github.com/go-vikunja/vikunja/issues/42
Resolves #950
Co-authored-by: viehlieb <pf@pragma-shift.net>
Co-committed-by: viehlieb <pf@pragma-shift.net>
This way the config module can already use the log module with the same result (default logging to StdOut with Level INFO, same output as before) but ENV variables can already change the logging of config file related log output). It is now possible to dump as a cronjob without having to filter the default log about the used config file.
Also:
- all logging modules are now configurable when initializing which makes testing easier
- viper dependency removed from logging
- log correct settings when configured error level is invalid
- deprecation of value "false" for log.standard and log.events (already not mentioned in https://vikunja.io/docs/config-options/)
Co-authored-by: Berengar W. Lehr <Berengar.Lehr@uni-jena.de>
Reviewed-on: vikunja/api#1606
Reviewed-by: konrad <k@knt.li>
Co-authored-by: Peter H0ffmann <hoffmannp@noreply.kolaente.de>
Co-committed-by: Peter H0ffmann <hoffmannp@noreply.kolaente.de>
