github-starred/vikunja
2
0
Fork 0
mirror of https://github.com/go-vikunja/vikunja.git synced 2026-05-05 19:18:16 -05:00
Code Issues 690 Packages Projects Releases 11 Wiki Activity

Task list items with same name are linked together #462

New Issue
Closed
opened 2025-11-01 20:56:31 -05:00 by GiteaMirror · 0 comments
GiteaMirror commented 2025-11-01 20:56:31 -05:00
Owner
Copy Link

Originally created by @vikunja-bot on GitHub (Apr 1, 2025).

Original issue by polgarc on 2024-01-30T19:03:18.000Z

Description

If I copy-paste a task item, they become kind of linked together: if I click on one of them, all the copies are ticked too.
This doesn't seem to be 100% consistent though: sometime not all of them get ticked, overall it's very confusing experience.

After some more testing it seems that the issue is not related to the copy-paste, rather the items having the same name. If you simply type the same item names instead of copy-paste, the issue occurs.

Steps to reproduce:

  1. Create a task
  2. Edit the description, add a 'Task list' item with a name
  3. Select and copy the row (ctrl+c)
  4. Paste it a few times below (ctrl+v)
  5. Save the description
  6. Click on the first item
  7. All of them gets ticked (sometimes only after a refresh).

Vikunja Frontend Version

0.22.1+10-0484923b8a

Vikunja API Version

v0.22.1+2-78353d1ffe

Browser and version

Firefox 122.0 (Linux)

Can you reproduce the bug on the Vikunja demo site?

Yes

Screenshots

item2 was copied a few times:

image

After clicking on the first item2:

image

After clicking on the first item2 again, they look like on the first screen shot.

Original issue on Gitea

@kolaente commented on 2024-02-05T11:04:16.000Z:

Well that should not happen. I'll take a look.

@kolaente commented on 2024-02-14T13:14:32.000Z:

Fixed in 3969f6ae66 - please check with the next unstable build (ready in ~45 min) or on try.

polgarc commented on 2024-02-14T16:00:16.000Z:

Thank you!
However I checked the demo instance (v0.23.0+46-827c43fe12) , and it seems all items have the same data-id, and the issue still persists. Tried with Firefox 122.0 and Chromium 121.0.6167.160 on Linux.

image

@kolaente commented on 2024-02-17T11:26:44.000Z:

Now fixed in 32edef2d38.

polgarc commented on 2024-02-17T21:42:44.000Z:

I'm sorry but this still doesn't work, tried with v0.23.0+49-32edef2d38. Also checked out and ran main locally, same: all items have the same id.
I think createRandomID() is only evaluated once, and not for each TaskItem. According to this issue, this approach won't even work.

BTW thanks for your time and effort - really appreciate it.

@kolaente commented on 2024-02-17T21:50:26.000Z:

Looks like this is a far deeper problem rooted in tiptap. I've tried the last few hours to make this work without actually getting to it. The root cause is from the comparison of nodes. If we take the text only, that will mark items as duplicate when they have the same text (as described here originally).
And what confuses me the most is how it sometimes is able to assign a random id to each item, just not consistently (I've tested this locally before closing this issue and it seemed to work fine).

Seems like their unique ID extension is the way out here, but that's probably not an option for an open-source project. I've emailed them about this, let's see what we get back.

@kolaente commented on 2024-02-17T22:16:19.000Z:

I've reverted the changes for now so that it works as long as the task items have different text. Moved the id changes so far to a new branch: https://kolaente.dev/vikunja/vikunja/compare/main...fix/tiptap-task-list

@kolaente commented on 2024-03-05T22:10:02.000Z:

Also mentioned here: https://community.vikunja.io/t/task-list-in-description-glitchy/2087/3

polgarc commented on 2024-06-10T06:36:38.000Z:

@dpschen May I ask why was this closed? It's still an issue, tried with the latest commit (v0.23.0+698-165d046307).

polgarc commented on 2024-10-15T09:14:18.000Z:

This is still an issue, just tried with v0.24.1-313-3e9c41cfc6 on https://try.vikunja.io/.

stepanov1975 commented on 2024-10-15T13:30:01.000Z:

Yep, the task list still completely broken

Originally created by @vikunja-bot on GitHub (Apr 1, 2025). _Original issue by polgarc on 2024-01-30T19:03:18.000Z_ ### Description If I copy-paste a task item, they become kind of linked together: if I click on one of them, all the copies are ticked too. This doesn't seem to be 100% consistent though: sometime not all of them get ticked, overall it's very confusing experience. After some more testing it seems that the issue is not related to the copy-paste, rather the items having the same name. If you simply type the same item names instead of copy-paste, the issue occurs. Steps to reproduce: 1. Create a task 2. Edit the description, add a 'Task list' item with a name 3. Select and copy the row (ctrl+c) 4. Paste it a few times below (ctrl+v) 5. Save the description 6. Click on the first item 7. All of them gets ticked (sometimes only after a refresh). ### Vikunja Frontend Version 0.22.1+10-0484923b8a ### Vikunja API Version v0.22.1+2-78353d1ffe ### Browser and version Firefox 122.0 (Linux) ### Can you reproduce the bug on the Vikunja demo site? Yes ### Screenshots `item2` was copied a few times: ![image](/attachments/88c02a6a-c9ab-4815-ad98-387e7b89d94e) After clicking on the first `item2`: ![image](/attachments/d95fa613-bbae-4582-9839-bfa4ce94d804) After clicking on the first `item2` again, they look like on the first screen shot. [Original issue on Gitea](https://kolaente.dev/vikunja/vikunja/issues/2091) --- _**@kolaente** commented on 2024-02-05T11:04:16.000Z_: Well that should not happen. I'll take a look. --- _**@kolaente** commented on 2024-02-14T13:14:32.000Z_: Fixed in https://kolaente.dev/vikunja/vikunja/commit/3969f6ae663ef30896454eb228dc478cf9cf14a3 - please check with the next unstable build (ready in ~45 min) or on try. --- _**polgarc** commented on 2024-02-14T16:00:16.000Z_: Thank you! However I checked the demo instance (`v0.23.0+46-827c43fe12`) , and it seems all items have the same `data-id`, and the issue still persists. Tried with Firefox 122.0 and Chromium 121.0.6167.160 on Linux. ![image](/attachments/ab327dac-dbec-4302-8b62-e1b98d8f6b27) --- _**@kolaente** commented on 2024-02-17T11:26:44.000Z_: Now fixed in 32edef2d383292531e821b3a471ba30504ac3ea9. --- _**polgarc** commented on 2024-02-17T21:42:44.000Z_: I'm sorry but this still doesn't work, tried with `v0.23.0+49-32edef2d38`. Also checked out and ran `main` locally, same: all items have the same id. I think [createRandomID()](https://kolaente.dev/vikunja/vikunja/src/branch/main/frontend/src/components/input/editor/TipTap.vue#L397) is only evaluated once, and not for each `TaskItem`. According to [this issue](https://github.com/ueberdosis/tiptap/issues/2661), this approach won't even work. BTW thanks for your time and effort - really appreciate it. --- _**@kolaente** commented on 2024-02-17T21:50:26.000Z_: Looks like this is a far deeper problem rooted in tiptap. I've tried the last few hours to make this work without actually getting to it. The root cause is from the comparison of nodes. If we take the text only, that will mark items as duplicate when they have the same text (as described here originally). And what confuses me the most is how it sometimes _is_ able to assign a random id to each item, just not consistently (I've tested this locally before closing this issue and it seemed to work fine). Seems like [their unique ID](https://tiptap.dev/docs/editor/api/extensions/unique-id) extension is the way out here, but that's probably not an option for an open-source project. I've emailed them about this, let's see what we get back. --- _**@kolaente** commented on 2024-02-17T22:16:19.000Z_: I've reverted the changes for now so that it works as long as the task items have different text. Moved the id changes so far to a new branch: https://kolaente.dev/vikunja/vikunja/compare/main...fix/tiptap-task-list --- _**@kolaente** commented on 2024-03-05T22:10:02.000Z_: Also mentioned here: https://community.vikunja.io/t/task-list-in-description-glitchy/2087/3 --- _**polgarc** commented on 2024-06-10T06:36:38.000Z_: @dpschen May I ask why was this closed? It's still an issue, tried with the latest commit (`v0.23.0+698-165d046307`). --- _**polgarc** commented on 2024-10-15T09:14:18.000Z_: This is still an issue, just tried with `v0.24.1-313-3e9c41cfc6` on https://try.vikunja.io/. --- _**stepanov1975** commented on 2024-10-15T13:30:01.000Z_: Yep, the task list still completely broken
GiteaMirror added the kind/bug label 2025-11-01 20:56:31 -05:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
area/api
area/attachments
area/auth
area/avatars
area/backup-restore
area/caldav
area/calendar-view
area/comments
area/config
area/database
area/desktop
area/docker
area/email
area/favorites
area/filters
area/frontend
area/gantt
area/i18n
area/import-export
area/internal-code
area/kanban
area/labels
area/list-view
area/mobile
area/notifications
area/permissions
area/projects
area/pwa
area/recurring-tasks
area/reminders
area/search
area/shortcuts
area/subtasks
area/sync
area/table-view
area/task-editor
area/task-metadata
area/task-relations
area/teams
area/theming
area/time-tracking
area/typesense
area/views
area/webhooks
bug
changes requested
concern/accessibility
concern/performance
concern/regression
concern/ux
confirmed
db/mysql
dependencies
enhancement
good first issue
help wanted
integration/inbound
integration/outbound
kind/bug
kind/feature
needs reproduction
pull-request
Mirrored from GitHub Pull Request
 question
security
support
upstream issue
waiting for reply
wontfix
No Label kind/bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/vikunja#462
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?