vikunja icon indicating copy to clipboard operation
vikunja copied to clipboard

labels are not assigned/created together with task

Open vikunja-bot opened this issue 10 months ago • 0 comments

Original issue by k2s on 2022-06-18T11:27:32.000Z

I created test script based on attachment_from_scratch.sh

#!/usr/bin/env bash

curl -X POST http://localhost:3456/api/v1/register -H 'Content-Type: application/json' -d '{"username":"demo","password":"demo","email":"[email protected]"}'

BEARER=`curl -X POST -H 'Content-Type: application/json' -d '{"username": "demo", "password":"demo"}' localhost:3456/api/v1/login | jq -r '.token'`
echo "Bearer: $BEARER"

# create first list
curl -X PUT localhost:3456/api/v1/namespaces/1/lists  -H 'Content-Type: application/json' -H "Authorization: Bearer $BEARER" -d '{"title":"list"}'

# create labels
curl -X PUT localhost:3456/api/v1/labels  -H 'Content-Type: application/json' -H "Authorization: Bearer $BEARER" -d '{"title":"created with label"}'
curl -X PUT localhost:3456/api/v1/labels  -H 'Content-Type: application/json' -H "Authorization: Bearer $BEARER" -d '{"title":"label assigned later"}'

# craete simple task
curl -X PUT localhost:3456/api/v1/lists/1  -H 'Content-Type: application/json' -H "Authorization: Bearer $BEARER" -d '{"title":"simple task"}'

# create task with existing labels
curl -X PUT localhost:3456/api/v1/lists/1  -H 'Content-Type: application/json' -H "Authorization: Bearer $BEARER" -d '{"title":"task with existing label", "labels": [{"id": 1}]}'

# create task with new label 
curl -X PUT localhost:3456/api/v1/lists/1  -H 'Content-Type: application/json' -H "Authorization: Bearer $BEARER" -d '{"title":"task with new label", "labels": [{"title": "label created with task"}]}'

# craete task and then set label
ID=`curl -X PUT localhost:3456/api/v1/lists/1  -H 'Content-Type: application/json' -H "Authorization: Bearer $BEARER" -d '{"title":"task and later label"}' | jq -r '.id'`
curl -X POST localhost:3456/api/v1/tasks/${ID}/labels/bulk  -H 'Content-Type: application/json' -H "Authorization: Bearer $BEARER" -d '{"labels": [{"id": 2}]}'

Only 1 task will have label assigned. Correct would be if 3 would have label assigned.

Original issue on Gitea


@kolaente commented on 2022-06-18T12:16:03.000Z:

Which one is assigned as expected, the last one?

For creating a task and passing the label along this is simply not implemented.

Changing the labels during updates is a bit more complicated: https://kolaente.dev/vikunja/api/src/branch/main/pkg/models/tasks.go#L1050-L1065 Now, it's been a while since I wrote that comment so it might be time to revisit the mechanism.


k2s commented on 2022-06-18T18:23:10.000Z:

The last one works. I would expect that all 3 requests containing labels should work.

It is not so important for user interaction, but it makes diferrence when mass importing.

Was not thinking about permission problem, but should we not simply:

  • if labels array is provided on task create/update
  • we should check permission (was not looking in code how it is done for now) for all labels
  • refuse the whole request if at least access to 1 label is restricted

The task with new label request is different problem, it requires to get or create label.

All this is only about bulk operation efficiency and not very critical.

It should be at least documented in https://try.vikunja.io/api/v1/docs#tag/task.


@kolaente commented on 2022-06-18T19:06:47.000Z:

We actually do have the current user in the Update context so that we could implement adding labels while creating a task. As I said, it's been a while since I wrote that comment :)

As you outlined it is the way to go. I'd just like to check if there's an existing label and use that before creating a new one - or we could delegate that to the client and only check if there's an ID present in the label object and if that's the case check if the user can use that label and use it. If not, create and add it.

+1 for this should be documented.

Now, if we allow this for labels during creation, what about other related entities like assignees?


k2s commented on 2022-06-20T19:16:58.000Z:

My opinion:

  • assignees - only existing by ID
  • attachments - also create new
  • labels - also create new
  • related_tasks - only existing
  • subscription - only existing user

@kolaente commented on 2022-06-29T19:23:39.000Z:

I think that makes sense.

Just a note, a user can only subscribe themselves to a task, it is not possible to subscribe other people to a task or list.

vikunja-bot avatar Apr 01 '25 11:04 vikunja-bot