github-starred/vikunja
2
0
Fork 0
mirror of https://github.com/go-vikunja/vikunja.git synced 2025-12-05 19:16:51 -06:00
Code Issues 219 Packages Projects Releases 2 Wiki Activity

[PR #1638] fix(kanban): repeating tasks dates won't update when moved in done bucket #1637

New Issue
Open
opened 2025-11-01 21:24:23 -05:00 by GiteaMirror · 0 comments
GiteaMirror commented 2025-11-01 21:24:23 -05:00
Owner
Copy Link

📋 Pull Request Information

Original PR: https://github.com/go-vikunja/vikunja/pull/1638
Author: @Biagio00
Created: 10/10/2025
Status: 🔄 Open

Base: main ← Head: main

📝 Commits (4)

  • 5ace321 fix: repeating tasks don't update dates when moving in done bucket
  • 3a77b29 better fix for kanban recurring task not updating without copier
  • 96e66d9 added tests for dates update in repeating tasks when moved to done bucket
  • d754599 lint fix for previous commit

📊 Changes

6 files changed (+40 additions, -10 deletions)

View changed files

📝 pkg/db/fixtures/tasks.yml (+4 -1)
📝 pkg/models/kanban_task_bucket.go (+2 -2)
📝 pkg/models/kanban_task_bucket_test.go (+19 -1)
📝 pkg/models/task_collection_test.go (+11 -2)
📝 pkg/models/tasks.go (+1 -1)
📝 pkg/webtests/task_collection_test.go (+3 -3)

📄 Description

This is my first pull request ever. Suggestions on how to do better are welcome :)

When moving a repeating task in done bucket it doesn't update start/due/end dates. In the code it seems that you were trying to create a copy of the task to be used as oldTask that has Done set to false. Because task is a pointer, doing oldTask.Done = false changes the done state in task too, causing the updateDone function call to exit without changing dates.
My fix just uses golang native deep copy that is enough for updateDone calculations that should not need any pointer-property of Task.

Example with new behaviour:

  • Task configuration:
    immagine

  • Task in kanban:
    immagine

  • Task when moved to done column:
    immagine

Because the task doesn't go back to the original bucket immediately (it sticks in the done bucket until refresh), picking it up again from the done bucket and releasing it there causes the dates to update again. This might be a thing to consider but i feel it's unrelated from the fix in this pull request.

🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/go-vikunja/vikunja/pull/1638 **Author:** [@Biagio00](https://github.com/Biagio00) **Created:** 10/10/2025 **Status:** 🔄 Open **Base:** `main` ← **Head:** `main` --- ### 📝 Commits (4) - [`5ace321`](https://github.com/go-vikunja/vikunja/commit/5ace321b987956572150032aba0e6c266b26e6d5) fix: repeating tasks don't update dates when moving in done bucket - [`3a77b29`](https://github.com/go-vikunja/vikunja/commit/3a77b29816f239a9a214ad8e3fb19f1b525f0999) better fix for kanban recurring task not updating without copier - [`96e66d9`](https://github.com/go-vikunja/vikunja/commit/96e66d9abc4c7d075cdd33c2da3accb5dab4f61f) added tests for dates update in repeating tasks when moved to done bucket - [`d754599`](https://github.com/go-vikunja/vikunja/commit/d7545994ab89eb968dc5c7195b45a108d5f2e4f4) lint fix for previous commit ### 📊 Changes **6 files changed** (+40 additions, -10 deletions) <details> <summary>View changed files</summary> 📝 `pkg/db/fixtures/tasks.yml` (+4 -1) 📝 `pkg/models/kanban_task_bucket.go` (+2 -2) 📝 `pkg/models/kanban_task_bucket_test.go` (+19 -1) 📝 `pkg/models/task_collection_test.go` (+11 -2) 📝 `pkg/models/tasks.go` (+1 -1) 📝 `pkg/webtests/task_collection_test.go` (+3 -3) </details> ### 📄 Description This is my first pull request ever. Suggestions on how to do better are welcome :) When moving a repeating task in done bucket it doesn't update start/due/end dates. In the code it seems that you were trying to create a copy of the task to be used as `oldTask` that has `Done` set to `false`. Because `task` is a pointer, doing `oldTask.Done = false` changes the done state in `task` too, causing the `updateDone` function call to exit without changing dates. My fix just uses golang native deep copy that is enough for `updateDone` calculations that should not need any pointer-property of Task. Example with new behaviour: - Task configuration: <img width="667" height="315" alt="immagine" src="https://github.com/user-attachments/assets/af1f8e60-f414-42d3-92a6-b78239a0a275" /> - Task in kanban: <img width="300" height="173" alt="immagine" src="https://github.com/user-attachments/assets/a8ba57b6-ebb6-4bd2-81ff-4f1728d60613" /> - Task when moved to done column: <img width="288" height="160" alt="immagine" src="https://github.com/user-attachments/assets/9f0d2041-cf00-4aca-98aa-d3537641299b" /> Because the task doesn't go back to the original bucket immediately (it sticks in the done bucket until refresh), picking it up again from the done bucket and releasing it there causes the dates to update again. This might be a thing to consider but i feel it's unrelated from the fix in this pull request. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
GiteaMirror added the
pull-request
 label 2025-11-01 21:24:23 -05:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
area/api
area/caldav
area/filters
area/frontend
area/gantt
area/internal-code
area/typesense
bug
changes requested
confirmed
dependencies
enhancement
good first issue
help wanted
kind/bug
kind/feature
needs reproduction
pull-request
Mirrored from GitHub Pull Request
question
security
support
upstream issue
waiting for reply
wontfix
No Label
pull-request
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#1637
No description provided.
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?