Permissions on labels

Hi guys,

after the deployment of v2.3.0 I have the issues that labels seem to have an owner. I can no longer add any label to my tasks, onle the labels that I created myself. Is that the expected behaviour?

In our team we label tasks with shared labels like ‘operations’, ‘documentation’ and so on.

1 Like

I also have the same issue, seems like a critical bug @kolaente

Same issue here, I’m using Vikunja v2.3.0, self-hosted in using Docker (version 29.6.1). I attach a piece of the log:

time=2026-07-14T14:09:12.134Z level=ERROR component=http remote_ip=<my-ip-address> method=PUT uri=/api/v1/tasks/53/labels status=403 latency=640.671µs err=“code=403, message=Forbidden”`
time=2026-07-14T14:10:49.055Z level=ERROR component=http remote_ip=<my-ip-address> method=PUT uri=/api/v1/tasks/53/labels status=403 latency=626.441µs err=“code=403, message=Forbidden”
time=2026-07-14T14:12:12.394Z level=ERROR component=http remote_ip=<my-ip-address> method=PUT uri=/api/v1/tasks/54/labels status=403 latency=640.481µs err=“code=403, message=Forbidden”
time=2026-07-14T14:12:24.649Z level=ERROR component=http remote_ip=<my-ip-address> method=PUT uri=/api/v1/tasks/54/labels status=403 latency=605.503µs err=“code=403, message=Forbidden”
time=2026-07-14T14:12:42.142Z level=ERROR component=http remote_ip=<my-ip-address> method=PUT uri=/api/v1/tasks/54/labels status=403 latency=599.684µs err=“code=403, message=Forbidden”
time=2026-07-14T14:13:04.735Z level=ERROR component=http remote_ip=<my-ip-address> method=PUT uri=/api/v1/tasks/54/labels status=403 latency=639.659µs err=“code=403, message=Forbidden”

Is already available a patch version? @kolaente

Still an issue on v2.4 it seems. @kolaente It would be really good if you could look into this, as it stands now we have to stay on v2.2

I have a user that is part of a team, and the team is set to have admin access to a project. Even when the user is an admin of that team (sidenote, I’m not quite sure what the difference between being member or admin of the team is concerning access to the project which the “team” is set to be set to have admin access to the project).

That user can create tasks, assign users and so on, but adding labels is not allowed whatsoever. Removing labels is allowed, funnily enough. I’m not quite sure what is going there.

An admin user of the whole Vikunja instance however can add labels.

This is the log from Vikunja:

vikunja-1 | time=2026-07-29T12:11:59.811Z level=WARN msg=“Tried to create while not having the permissions for it (User: &{769 Active false 0 false false false false 0 0 0 0001-01-01 00:00:00 +0000 UTC 0001-01-01 00:00:00 +0000 UTC map 0 0001-01-01 00:00:00 +0000 UTC 0001-01-01 00:00:00 +0000 UTC })”
vikunja-1 | time=2026-07-29T12:11:59.811Z level=ERROR component=http remote_ip= method=PUT uri=/api/v1/tasks/11117/labels status=403 latency=28.589463ms user_agent=“Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:153.0) Gecko/20100101 Firefox/153.0” err=Forbidden

If you need extra info please let me know.

Is version 2.2 not affected by this bug? If so, I will carefully consider downgrading from version 2.3 to 2.2, since our team relies heavily on labels (and label-based filtering).

Yes, the bug was introduced in v2.3 and persists in v2.4 still

In the meantime, would it be helpful to open a GitHub issue for this bug?

I don’t want to put pressure on anyone, but since the issue was introduced in v2.3 and still persists in v2.4, a GitHub issue might make it easier for developers to track. They may not notice this community discussion right away.

There is now a PR to fix it: fix(labels): allow attaching labels via inherited child-project access by tink-bot · Pull Request #3374 · go-vikunja/vikunja · GitHub

This is now fixed in fix(labels): allow attaching labels via inherited child-project access by tink-bot · Pull Request #3374 · go-vikunja/vikunja · GitHub, please check with the next unstable build (should be ready for deployment in ~30min, also on try).

1 Like

Hi @kolaente sorry for the late reply! I updated our Vikunja instance to v2.5.0 and the issue seems to be resolved. Thank you for the update!

1 Like