github-starred/vikunja
2
0
Fork 0
mirror of https://github.com/go-vikunja/vikunja.git synced 2026-08-24 11:43:50 -05:00
Code Issues 690 Packages Projects Releases 13 Wiki Activity

[Feature Request] Be able to change KanBan buckets for a task from within the task. #381

New Issue
Open
opened 2025-11-01 20:55:31 -05:00 by GiteaMirror · 0 comments
GiteaMirror commented 2025-11-01 20:55:31 -05:00
Owner
Copy Link
Copy Source

Originally created by @vikunja-bot on GitHub (Apr 1, 2025).

Original issue by SteveDinn on 2021-06-03T22:42:09.000Z

From the task details view, I want to be able to switch the KanBan bucket that the task is in.

Imagine this workflow:

  • Start on the overview page, or from within the task details view of a parent task, or some other scenario where you can navigate directly to the details view of a task, but not from the KanBan board.
  • In this case, I'd like to be able to switch the KanBan bucket of a task without having to back out of the view that I'm in, switch over to KanBan (or worse, if I was in the overview, I'd have to go find the namespace and list, and then make sure I was in KanBan mode), then finally find the task and drag it over to the bucket I wanted.

I'm thinking of a simple drop-down combobox populated with the names of the KanBan buckets in that list. My KanBan buckets correspond to states that a task can be in, so I think this makes sense.

If there is already a way to do this, I haven't found it.

Thanks!!

Original issue on Gitea

@kolaente commented on 2021-06-04T20:45:22.000Z:

I think it would make sense to have this - added to the backlog.

smkent commented on 2022-04-17T04:45:02.000Z:

I want to add my vote for this as well. Other issue and task systems use task/issue status as the Kanban bucket/column name. In Jira or Linear for example, moving a task from one Kanban column (e.g. "Backlog") to another (e.g. "In Progress") changes the task status.

One way this could be implemented is with a new state property for tasks. This property could be free-form or selectable from a configurable set of states (similar to how other issue tracking systems let a user define workflow states). These states would then be the Kanban column names.

Also (optionally?) displaying this new task status next to tasks in the list view would also make Vikunja's task management featureset feel much more complete.

xeruf commented on 2022-07-08T14:46:41.000Z:

Or even better, let users select which properties to show in List/Table view and build multiple views, like in Notion ;)

xeruf commented on 2022-11-12T13:33:12.000Z:

Thought about it, and buckets should indeed equal task status.
This would make Kanban much easier and more useful and solve all these issues:

https://kolaente.dev/vikunja/frontend/issues/545
https://kolaente.dev/vikunja/frontend/issues/2246
https://kolaente.dev/vikunja/frontend/issues/2338

Thus Kanban would automatically start with two buckets and be in sync with the task list :)

dpschen commented on 2022-11-12T13:46:27.000Z:

Thus Kanban would automatically start with two buckets and be in sync with the task list :)

I'm against making this the default. Because:
When you think of think of the buckets as sections that get shown as buckets in the kanban view then having two 'reaL' sections by default isn't what you would want.

Maybe a new concept is needed for this, like grouping? So the task wouldn't actually 'be' in a done bucket but instead shown in a group based on their status.

When you think further one could also say that the namespaces / lists and what I just called sections (aka buckets) could all be of the same kind.
Making buckets more special than they are already currently would make our way to somthing like https://kolaente.dev/vikunja/api/issues/1198 more complex.

Just thinking loud here :)

SteveDinn commented on 2022-11-12T14:47:47.000Z:

When you think of think of the buckets as sections that get shown as buckets in the kanban view then having two 'reaL' sections by default isn't what you would want.

I will admit that I haven't had my second cup of coffee yet this morning, but I've read this several times, and I still don't understand what you're getting at. ELI5?

dpschen commented on 2022-11-12T15:22:31.000Z:

I'm refering here to what @xeruf said:

Thus Kanban would automatically start with two buckets and be in sync with the task list :)

@kolaente commented on 2022-11-12T20:55:44.000Z:

Thought about it, and buckets should indeed equal task status.
This would make Kanban much easier and more useful and solve all these issues:

How would you define the task status? Right now there's only done / not done and you'll need more buckets than two. Depends very much on the use case. I think having that flexibility is a good thing and something that should exist.

You could also add a new "status" field and allow configuring it per list but that would make things more complicated. At that point it would be easier to just allow selecting the kanban bucket on the task detail page.

Another option maybe worth exploring is parsing labels (like gitlab) and building a kanban board based on that. For example, having labels status/new, status/in-progress, status/in-review, status/done; then parsing these into the buckets new, in-progress, in-review and done.

Thus Kanban would automatically start with two buckets and be in sync with the task list :)

We could create a Done bucket when creating a new list, in addition to the default backlog bucket.

@kolaente commented on 2022-11-13T22:04:27.000Z:

Another option would be to not mark the task as done when clicking on it but instead move the task one bucket to the right (or left, with a setting). The task detail view would need to at least show what bucket the task is in to make easier to understand.

This would require each list to have a done bucket but that's not a huge problem.

I would also tie the task a lot more to the kanban board so if we're going that route it should be optional (aka add a setting to disable it).

xeruf commented on 2022-11-14T01:28:49.000Z:

Another option would be to not mark the task as done when clicking on it but instead move the task one bucket to the right (or left, with a setting). The task detail view would need to at least show what bucket the task is in to make easier to understand.

That's exactly what I meant :)

This would require each list to have a done bucket but that's not a huge problem.

I think this is actually a good thing

I would also tie the task a lot more to the kanban board so if we're going that route it should be optional (aka add a setting to disable it).

I have thought more about it, and I think the way to go will be to have no fixed Kanban view. Instead one should be able to create a kanban view grouped by a desired property, which might be the task status but could also be an assignee or the like, like in Notion.
Either way, there should be a way to add more task status options through which a task can be moved with one click as outlined above.

Another option maybe worth exploring is parsing labels (like gitlab) and building a kanban board based on that. For example, having labels status/new, status/in-progress, status/in-review, status/done; then parsing these into the buckets new, in-progress, in-review and done.

When we go into the generalisation, most task properties could be represented with labels technically, with the interface only being syntactic sugar for it.
Something to elaborate on in my upcoming essay :)

@kolaente commented on 2022-11-14T16:13:22.000Z:

I have thought more about it, and I think the way to go will be to have no fixed Kanban view. Instead one should be able to create a kanban view grouped by a desired property, which might be the task status but could also be an assignee or the like, like in Notion.

That's a direction I would like to go in the future. I'd say this too is more of a long-term goal than a short-term feature, but it's interesting nontheless.

xeruf commented on 2024-02-29T15:18:14.000Z:

Out work has been messy the last year, and one aspect has been the continuous failure of tools. I think this feature would singlehandedly change a lot - because we need separate lists but still one kanban board that provides an overview over everything.

Originally created by @vikunja-bot on GitHub (Apr 1, 2025). _Original issue by SteveDinn on 2021-06-03T22:42:09.000Z_ From the task details view, I want to be able to switch the KanBan bucket that the task is in. Imagine this workflow: * Start on the overview page, or from within the task details view of a parent task, or some other scenario where you can navigate directly to the details view of a task, but not from the KanBan board. * In this case, I'd like to be able to switch the KanBan bucket of a task without having to back out of the view that I'm in, switch over to KanBan (or worse, if I was in the overview, I'd have to go find the namespace and list, and then make sure I was in KanBan mode), then finally find the task and drag it over to the bucket I wanted. I'm thinking of a simple drop-down combobox populated with the names of the KanBan buckets in that list. My KanBan buckets correspond to states that a task can be in, so I think this makes sense. If there is already a way to do this, I haven't found it. Thanks!! [Original issue on Gitea](https://kolaente.dev/vikunja/vikunja/issues/1793) --- _**@kolaente** commented on 2021-06-04T20:45:22.000Z_: I think it would make sense to have this - added to the backlog. --- _**smkent** commented on 2022-04-17T04:45:02.000Z_: I want to add my vote for this as well. Other issue and task systems use task/issue status as the Kanban bucket/column name. In Jira or Linear for example, moving a task from one Kanban column (e.g. "Backlog") to another (e.g. "In Progress") changes the task status. One way this could be implemented is with a new state property for tasks. This property could be free-form or selectable from a configurable set of states (similar to how other issue tracking systems let a user define workflow states). These states would then be the Kanban column names. Also (optionally?) displaying this new task status next to tasks in the list view would also make Vikunja's task management featureset feel much more complete. --- _**xeruf** commented on 2022-07-08T14:46:41.000Z_: Or even better, let users select which properties to show in List/Table view and build multiple views, like in Notion ;) --- _**xeruf** commented on 2022-11-12T13:33:12.000Z_: Thought about it, and buckets should indeed equal task status. This would make Kanban much easier and more useful and solve all these issues: https://kolaente.dev/vikunja/frontend/issues/545 https://kolaente.dev/vikunja/frontend/issues/2246 https://kolaente.dev/vikunja/frontend/issues/2338 Thus Kanban would automatically start with two buckets and be in sync with the task list :) --- _**dpschen** commented on 2022-11-12T13:46:27.000Z_: > Thus Kanban would automatically start with two buckets and be in sync with the task list :) I'm against making this the default. Because: When you think of think of the buckets as sections that get shown as buckets in the kanban view then having two 'reaL' sections by default isn't what you would want. Maybe a new concept is needed for this, like grouping? So the task wouldn't actually 'be' in a done bucket but instead shown in a group based on their status. When you think further one could also say that the namespaces / lists _and_ what I just called sections (aka buckets) could all be of the same kind. Making buckets _more_ special than they are already currently would make our way to somthing like https://kolaente.dev/vikunja/api/issues/1198 more complex. Just thinking loud here :) --- _**SteveDinn** commented on 2022-11-12T14:47:47.000Z_: > When you think of think of the buckets as sections that get shown as buckets in the kanban view then having two 'reaL' sections by default isn't what you would want. I will admit that I haven't had my second cup of coffee yet this morning, but I've read this several times, and I still don't understand what you're getting at. ELI5? --- _**dpschen** commented on 2022-11-12T15:22:31.000Z_: I'm refering here to what @xeruf said: > Thus Kanban would automatically start with two buckets and be in sync with the task list :) --- _**@kolaente** commented on 2022-11-12T20:55:44.000Z_: > Thought about it, and buckets should indeed equal task status. This would make Kanban much easier and more useful and solve all these issues: How would you define the task status? Right now there's only done / not done and you'll need more buckets than two. Depends very much on the use case. I think having that flexibility is a good thing and something that should exist. You could also add a new "status" field and allow configuring it per list but that would make things more complicated. At that point it would be easier to just allow selecting the kanban bucket on the task detail page. Another option maybe worth exploring is parsing labels (like gitlab) and building a kanban board based on that. For example, having labels status/new, status/in-progress, status/in-review, status/done; then parsing these into the buckets new, in-progress, in-review and done. > Thus Kanban would automatically start with two buckets and be in sync with the task list :) We could create a Done bucket when creating a new list, in addition to the default backlog bucket. --- _**@kolaente** commented on 2022-11-13T22:04:27.000Z_: Another option would be to not mark the task as done when clicking on it but instead move the task one bucket to the right (or left, with a setting). The task detail view would need to at least show what bucket the task is in to make easier to understand. This would require each list to have a done bucket but that's not a huge problem. I would also tie the task a lot more to the kanban board so if we're going that route it should be optional (aka add a setting to disable it). --- _**xeruf** commented on 2022-11-14T01:28:49.000Z_: > Another option would be to not mark the task as done when clicking on it but instead move the task one bucket to the right (or left, with a setting). The task detail view would need to at least show what bucket the task is in to make easier to understand. That's exactly what I meant :) > This would require each list to have a done bucket but that's not a huge problem. I think this is actually a good thing > I would also tie the task a lot more to the kanban board so if we're going that route it should be optional (aka add a setting to disable it). I have thought more about it, and I think the way to go will be to have no fixed Kanban view. Instead one should be able to create a kanban view grouped by a desired property, which might be the task status but could also be an assignee or the like, like in Notion. Either way, there should be a way to add more task status options through which a task can be moved with one click as outlined above. > Another option maybe worth exploring is parsing labels (like gitlab) and building a kanban board based on that. For example, having labels status/new, status/in-progress, status/in-review, status/done; then parsing these into the buckets new, in-progress, in-review and done. When we go into the generalisation, most task properties could be represented with labels technically, with the interface only being syntactic sugar for it. Something to elaborate on in my upcoming essay :) --- _**@kolaente** commented on 2022-11-14T16:13:22.000Z_: > I have thought more about it, and I think the way to go will be to have no fixed Kanban view. Instead one should be able to create a kanban view grouped by a desired property, which might be the task status but could also be an assignee or the like, like in Notion. That's a direction I would like to go in the future. I'd say this too is more of a long-term goal than a short-term feature, but it's interesting nontheless. --- _**xeruf** commented on 2024-02-29T15:18:14.000Z_: Out work has been messy the last year, and one aspect has been the continuous failure of tools. I think this feature would singlehandedly change a lot - because we need separate lists but still one kanban board that provides an overview over everything.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
area/api
area/attachments
area/auth
area/avatars
area/backup-restore
area/caldav
area/calendar-view
area/comments
area/config
area/database
area/desktop
area/docker
area/email
area/favorites
area/filters
area/frontend
area/gantt
area/i18n
area/import-export
area/internal-code
area/kanban
area/labels
area/list-view
area/mobile
area/notifications
area/permissions
area/projects
area/pwa
area/recurring-tasks
area/reminders
area/search
area/shortcuts
area/subtasks
area/sync
area/table-view
area/task-editor
area/task-metadata
area/task-relations
area/teams
area/theming
area/time-tracking
area/typesense
area/views
area/webhooks
bug
changes requested
concern/accessibility
concern/performance
concern/regression
concern/ux
confirmed
db/mysql
dependencies
enhancement
good first issue
help wanted
integration/inbound
integration/outbound
kind/bug
kind/feature
needs reproduction
pull-request
Mirrored from GitHub Pull Request
 pull-request
Mirrored from GitHub Pull Request
 pull-request
Mirrored from GitHub Pull Request
 question
security
support
upstream issue
waiting for reply
wontfix
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
GiteaMirror ninjasurge (Kaehlen Rog)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/vikunja#381