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

Open
opened 2021-06-03 22:42:09 +00:00 by SteveDinn · 12 comments

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!!

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!!
konrad added the
kind/feature
label 2021-06-04 20:33:32 +00:00
Owner

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

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

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.

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.

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

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

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

vikunja/frontend#545
vikunja/frontend#2246
vikunja/frontend#2338

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

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 :)
Member

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 vikunja/api#1198 more complex.

Just thinking loud here :)

> 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 :)
Author

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?

> 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?
Member

I'm refering here to what @xeruf said:

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

I'm refering here to what @xeruf said: > Thus Kanban would automatically start with two buckets and be in sync with the task list :)
Owner

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.

> 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.
Owner

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).

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).

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 :)

> 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 :)
Owner

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.

> 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.

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.

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 Milestone
No Assignees
5 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: vikunja/vikunja#1793
No description provided.