Labels local to a namespace (or even a list)

Feature Discussion
1

The problem

I’ve been thinking a lot of about labels. I like to use labels. They help with organization. However, when you use them a lot, your list of labels can quickly get polluted. Across everything on your Vikunja instance, you most likely have different namespaces and lists that pertain to completely separate logical domains (i.e., the tasks therein have little to no association with each other) but labels cannot be separated in this way. Tasks in different logical domains are able are able to have labels applied to them that make no sense, because they were intended for a different class of task, or a task in a different logical domain.

A potential solution?

I don’t know if this has been thought about before, but I think it would be great to have labels be able to exist at different levels, such as:

  • Global - This is the behaviour as it is today, with every label being applicable everywhere.
  • Namespace - Namespace labels are only visible to lists and tasks within the namespace in which the label was created.
  • List - List labels are only visible to the tasks in the list in which they were created (maybe this one is too granular).

Other considerations:

Labels should be able to have the same name, as long as their scopes do not conflict: A label cannot exist twice within the same hierarchy (Global → Namespace → List). This implies that:

  • A list may not have a label with the same name as one of its parent namespace’s labels.
  • A list may not have a label with the same name as a global label.
  • A namespace may not have a label with the same name as a global label.
  • A label may be duplicated in peer lists or peer namespaces.
  • A label may be duplicated between a namespace and a peer namespace’s list.

We would need to be able to specify the hierarchy of a label when creating it.

We would probably need a way to change the hierarchy level of a label, i.e., move it from a list-level label to a namespace-level label. If not this, then be able to migrate to another label so we only have to worry about conflicts on label creation:

  • Search for a given label
  • Apply a new label (perhaps with a different scope) to all search results
  • Remove the original label

Summary

I’ve tried to be detailed and verbose here to convey what I’ve been thinking about. I think it could be a useful feature. I’m interested to hear what other people have to say about it.

2

Thanks for the comment! I had some thoughts related to this as well.

I think that makes sense. I’d definitely keep the global level as that’s what people are used to. It would help as well with sharing a label because right now I don’t think it’s clear how that works and the implications of it. Also, the code in the api to make it work is quite complex.

Since namespaces will go away, scoping a label to a namespace won’t make sense. At the same time, projects will be nestable, which add another implicit layer of where a label can be applied to.

What about the case where I create a global label, and you want to create a label with the same title in a project we both have access to?

What about the case where I create a global label, add it to a task and give you access to that task? Should you see that label in your overview or should it be “scoped” to the project the task belongs to? Should you be able to add that label to other tasks within the same list?

3

Hmmm… Maybe duplicate label names are allowed, but if there is a conflict, they show with a scope-defining prefix.

Say there is a global label foo and there is also a namespace label foo. Then everywhere that there might be ambiguity, the scope is also displayed: global:foo vs. namespace:foo. This might imply that certain characters (: in my example) are not permitted in label names.

Edit: I just re-read your response and saw that namespaces are going away. Is there a plan or roadmap that I should have been reading? What’s happening to them?

4

That could work. I’m not sure about the added complexity though.

Namespaces will be gone completely, in their place it will be possible to nest lists (now called projects).
The projects transition is done already and there’s an ongoing PR for the namespace migration: #1362 - feat: remove namespaces, make projects infinitely nestable - api - Gitea and https://kolaente.dev/vikunja/frontend/pulls/3323

5

In this case, all we’d need is global and project-level labels, and each task would just have to check it’s labels against not only global labels, but its list’s labels and it’s parent lists’ labels, until we get to a list that isn’t parented, or we encounter a recursive list parentage.

I think it’s doable, but I haven’t looked at the code in any depth. Do you feel like it would really be overly complicated?

6

It is doable, maybe even less complicated than the current solution.

1 Like