Allow to associate kanban buckets to labels

Feature Discussion
1

This suggestion is an attempt to enable the following requests:

To start with, I’ll state that from my user perspective, kanban buckets have a strong semblance to labels, only with a very convenient user interface for attaching / detaching labels to / from tasks. This idea would (allow to) make that semblance more explicit:

Allow to associate an arbitrary label with a (manual) bucket

  1. Moving a task into a bucket with an assigned label will automatically attach that label to the task (Rule 3, below may trigger, subsequently).
  2. Moving a task out of a labeled bucket will remove that label from the task (Rule 4, below may trigger, subsequently).
  3. When assigning a new label AND that label is associated with a bucket, the task will be moved into that bucket.
    3a) This will have to happen for all views containing a bucket with that label.
    3b) This may imply Rule 2, above: I.e. if in this process, the task is moved out of a labeled bucket, the corresponding label will be removed, too.
  4. When removing a label from a task AND that label is associated with a bucket AND the task is currently in that bucket, the task will be moved out of that bucket. Usually this will mean moving it into the default bucket (see below)
    4a) This will have to happen for all views containing a bucket with that label.
    4b) Logically, this might subsequently trigger Rule 1, implicitly, i.e. attaching the label of the default bucket. See edge-case considerations, below, however.

Edge case considerations:
Conceptually, the above implies that labels associated to kanban buckets become mutually exclusive to some extent. E.g. if a first kanban view has buckets with attached labels A, B, C, and a second kanban view has buckets with labels X, Y, Z, then (A,B,C) will form an exclusive set, and so will (X,Y,Z). It will still be quite possible for a task to have, e.g. labels A and Y at the same time, however.
What happens, if there is overlap between the labels used in different kanban views? Well, first, if the same (sub)set of labels is used, the two views will become synchronized, implicity. Second, if overlapping, but not identical sets are used (e.g. A, B, C, and C, D, E), moving a task from a “shared” bucket into a non-shared bucket (e.g. from C to E) will move the task to the default bucket in the other view. This may or may not be desired, but since this is an opt-in feature, I do not see much of a problem, here.
Assigning a label to a default bucket could create an infinite loop / an inconsistency in conjunction with action 4b), above. To avoid this, default buckets either should not be allowed to carry a label, or all default buckets (across views) would have to use the same label. I lean towards the first, to allow a task to be in the default bucket in one view, but a non-shared labelled bucket in another view.

2

Ok, sorry for the above wall of text. TL;DR: If we could define a 1:1-relationship between a label and a kanban bucket, this would effectively allow to see, manipulate, and filter by the kanban bucket in other types of views, implicitly. Some complexity arises from the fact that there could be multiple kanban views, but this can be solved.

3

Focalboard enables a similar functionality.

Where Focalboard allows many data types to be added for entries, only single-item categories can be used as kanban buckets. (That is, you can assign just one category per item but multiple tags are OK)

4

Zenkit Projects has batches of labels, and you can set and given batch of labels as column heads. It’s pretty much the only thing I miss about Zk. I’ve never requested it as a feature here because it sounds nontrivial to implement. That said, since we’re discussing tag/bucket relationships, I wanted to float the idea.

5

Added a vote. I think this is a great idea and would allow amazing functionality for Saved Filters, both within Vikunja and apps like Tasks.org.

6

I second this.
Or even better, allow the user to specify which attributes get changed on a bucket swap.
Exactly like the “Done bucket” but for user specified properties.

I’m fairly new and just want to say to the devs: I love it! It works amazingly well, really impressed with the performance. :slight_smile:

7

Yes, exactly, this is all about generalizing that concept to some degree.

That would open some fascinating possibilities, but I fear, it may also bring whole new sorts of trouble, that I wouldn’t know how to solve. Others might, though, so I’ll try to spell it out, for brainstorming, but since that’s another large wall of text, I’ll hide it in a expandable section:

Expand, if you have some time to spare...

First, difficulties may arise on a conceptual level. Suppose, for example, we have four buckets, “Do today”, “Do tomorrow”, “No deadline”, “Needs feedback”. Now, the first two would be associated to a corresponding due date (and, while not mission critical, I would find that useful, myself, sometimes). Moving from either to bucket 3 should be expected to clear any due date. But what would we actually expect to happen about the due date, when moving to bucket 4? And - as the answer to that question may vary between use-cases - how would we be able to specify the desired behavior in a simple UI?

Speaking more theoretically, problems arise, as several independent properties/attributes are involved. My original suggestion does not offer a solution to that problem, but simply avoids it by being more limited.

A second vector of difficulties arises, if we want to have a two-way solution (and I very much think, we do), i.e. moving from one kanban bucket to another should change some properties, but also a change in that property should affect the kanban bucket. Here, I can think of three general approaches:

  • We could simply have “kanban bucket” as a new “first class” property that can also be shown and manipulated in other views / used in filters. In a way that may be the most straight-forward, but it would mean adding dedicated - if perhaps simple - UI to all views for that new property. Also, of course, it’s still limited to only one property.
  • My suggestion about optionally associating buckets with labels. I’ll not summarize, again, but here I’ll point out that I’ve essentially formulated it as an algorithm. In theory, that can be extended to a multitude of properties, but beyond the conceptual problems (“What’s the bucket for a task that needs to be done today and needs feedback?”), if arbitrary properties could be assigned to kanban buckets, then any change in any property would need to trigger an algorithm to determine the new kanban bucket. I’d be afraid of performance problems, and maintainability (code-complexity) problems, here.
  • The problem might not have to be attacked in a purely imperative programming manner, however: Going from a changed property to a changed bucket could also be handled by a filter. I.e. on some level, we’d have a mix between “manual” and “filtered” bucket views: Tasks would be sorted into a bucket by a filter based on a property, but it would still be possible to move them manually, and this would result in a corresponding change in the property. Sounds perfect to me, as long as I’m not trying to think about what magic will be needed to actually define such “corresponding changes”.