Multiple labels with same title (importing via CalDav) #1435

Closed
opened 2023-03-17 14:06:22 +00:00 by ce72 · 4 comments
Contributor

Description

Importing CalDav Categories seems to always create new labels, even if a label with the same title exists already for the current user.

Maybe (but I am not very sure) the reason labels from CalDAv are replicated is in https://kolaente.dev/vikunja/api/src/branch/main/pkg/routes/caldav/listStorageProvider.go#L420. labels that are returned from vTask.Update() don't have their id filled in. So comparing by ids cannot work.

But why should we have the same label title multiple times at all?

Vikunja Frontend Version

vikunja/frontend:0.20.5

Vikunja API Version

vikunja/api:0.20.4

Browser and version

No response

Can you reproduce the bug on the Vikunja demo site?

Yes

Screenshots

No response

### Description Importing CalDav Categories seems to always create new labels, even if a label with the same title exists already for the current user. Maybe (but I am not very sure) the reason labels from CalDAv are replicated is in https://kolaente.dev/vikunja/api/src/branch/main/pkg/routes/caldav/listStorageProvider.go#L420. labels that are returned from `vTask.Update()` don't have their id filled in. So comparing by ids cannot work. But why should we have the same label title multiple times at all? ### Vikunja Frontend Version vikunja/frontend:0.20.5 ### Vikunja API Version vikunja/api:0.20.4 ### Browser and version _No response_ ### Can you reproduce the bug on the Vikunja demo site? Yes ### Screenshots _No response_
ce72 added the
kind/bug
label 2023-03-17 14:06:22 +00:00
Owner

But why should we have the same label title multiple times at all?

There might be cases where you get access to a label via a shared task after you already created one with the same name yourself.

> But why should we have the same label title multiple times at all? There might be cases where you get access to a label via a shared task after you already created one with the same name yourself.
Author
Contributor

Okay, I understand.

After stepping through it and few tests, I think that the following quick fix might already help:

Index: pkg/routes/caldav/listStorageProvider.go
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
diff --git a/pkg/routes/caldav/listStorageProvider.go b/pkg/routes/caldav/listStorageProvider.go
--- a/pkg/routes/caldav/listStorageProvider.go	(revision 4018bd6078cceb8c0fb144ac77ded07572bb4ecf)
+++ b/pkg/routes/caldav/listStorageProvider.go	(date 1679637339016)
@@ -411,13 +411,13 @@
 		return err
 	}
 
-	labelMap := make(map[int64]*models.Label)
+	labelMap := make(map[string]*models.Label)
 	for _, l := range existingLabels {
-		labelMap[l.ID] = &l.Label
+		labelMap[l.Title] = &l.Label
 	}
 
 	for _, label := range labels {
-		if l, has := labelMap[label.ID]; has {
+		if l, has := labelMap[label.Title]; has {
 			*label = *l
 			continue
 		}

Okay, I understand. After stepping through it and few tests, I think that the following quick fix might already help: ``` Index: pkg/routes/caldav/listStorageProvider.go IDEA additional info: Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP <+>UTF-8 =================================================================== diff --git a/pkg/routes/caldav/listStorageProvider.go b/pkg/routes/caldav/listStorageProvider.go --- a/pkg/routes/caldav/listStorageProvider.go (revision 4018bd6078cceb8c0fb144ac77ded07572bb4ecf) +++ b/pkg/routes/caldav/listStorageProvider.go (date 1679637339016) @@ -411,13 +411,13 @@ return err } - labelMap := make(map[int64]*models.Label) + labelMap := make(map[string]*models.Label) for _, l := range existingLabels { - labelMap[l.ID] = &l.Label + labelMap[l.Title] = &l.Label } for _, label := range labels { - if l, has := labelMap[label.ID]; has { + if l, has := labelMap[label.Title]; has { *label = *l continue } ```
Owner

That sounds like it could work.

That sounds like it could work.
ce72 closed this issue 2023-03-24 11:37:46 +00:00
Author
Contributor

Did not mean to close this, but I've created a PR which (when being merged) closes this issue.

Did not mean to close this, but I've created a PR which (when being merged) closes this issue.
konrad reopened this issue 2023-03-24 15:21:31 +00:00
Sign in to join this conversation.
No Milestone
No Assignees
2 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#1435
No description provided.