github-starred/vikunja
2
0
Fork 0
mirror of https://github.com/go-vikunja/vikunja.git synced 2026-03-12 01:59:34 -05:00
Code Issues 219 Packages Projects Releases 2 Wiki Activity

Inconsistent behavior of done_at field in tasks API when updating done status #607

New Issue
Closed
opened 2025-11-01 21:00:15 -05:00 by GiteaMirror · 1 comment
GiteaMirror commented 2025-11-01 21:00:15 -05:00
Owner
Copy Link

Originally created by @Plong-Wasin on GitHub (Sep 10, 2025).

Description

There appears to be an inconsistency in the way the done_at field is handled by the Vikunja tasks API endpoints (/api/v1/tasks/{id} and /api/v1/tasks/bulk) when updating the done status of a task.

Specifically, given a payload like:

{
    "done": true,
    "done_at": "2025-09-10T16:26:11+02:00"
}

and assuming the previous state was done = false, the following occurs:

  • On the first API request, done_at is set to the current server time instead of the provided timestamp.
  • On subsequent requests, done_at uses the timestamp from the payload as expected.

In another scenario, if the payload contains only:

{
    "done": true
}
  • On the first update, done_at is set to the current time as expected.
  • On the second update, done_at inexplicably changes to "0001-01-01T00:00:00Z", which appears to be a default or zero value rather than retaining the previous time or current timestamp.

It is unclear whether this behavior is intended or a bug. The expectation would generally be either:

  • When done is set to true and done_at is provided, the API should use the provided done_at timestamp consistently.
  • When done_at is omitted, the API should set done_at to the current timestamp when marking a task done and not revert to a zero time on subsequent updates.

Please investigate whether this inconsistent handling of the done_at field on task updates is by design or an issue that needs addressing.

Steps to reproduce:

  1. Update a task with { "done": true, "done_at": "<timestamp>" } from a previously undone state.
  2. Observe that initially, the done_at is set to the current time, not the provided timestamp.
  3. Repeat the update with the same payload, and observe done_at uses the provided timestamp.
  4. Update a task with { "done": true } only from undone state.
  5. Observe that done_at is set to current time first, but changes to "0001-01-01T00:00:00Z" on repeated updates.

Additional context:
This behavior was observed on the API at https://try.vikunja.io/api/v1/tasks/{id} and /api/v1/tasks/bulk. Clarification on intended implementation of done_at handling when toggling task completion would be appreciated.

Vikunja Version

v1.0.0-rc1-125-a1e95789

Browser and version

No response

Can you reproduce the bug on the Vikunja demo site?

Yes

Screenshots

No response

Originally created by @Plong-Wasin on GitHub (Sep 10, 2025). ### Description There appears to be an inconsistency in the way the `done_at` field is handled by the Vikunja tasks API endpoints (`/api/v1/tasks/{id}` and `/api/v1/tasks/bulk`) when updating the `done` status of a task. Specifically, given a payload like: ```json { "done": true, "done_at": "2025-09-10T16:26:11+02:00" } ``` and assuming the previous state was `done = false`, the following occurs: - On the first API request, `done_at` is set to the current server time instead of the provided timestamp. - On subsequent requests, `done_at` uses the timestamp from the payload as expected. In another scenario, if the payload contains only: ```json { "done": true } ``` - On the first update, `done_at` is set to the current time as expected. - On the second update, `done_at` inexplicably changes to `"0001-01-01T00:00:00Z"`, which appears to be a default or zero value rather than retaining the previous time or current timestamp. It is unclear whether this behavior is intended or a bug. The expectation would generally be either: - When `done` is set to true and `done_at` is provided, the API should use the provided `done_at` timestamp consistently. - When `done_at` is omitted, the API should set `done_at` to the current timestamp when marking a task done and not revert to a zero time on subsequent updates. Please investigate whether this inconsistent handling of the `done_at` field on task updates is by design or an issue that needs addressing. Steps to reproduce: 1. Update a task with `{ "done": true, "done_at": "<timestamp>" }` from a previously undone state. 2. Observe that initially, the `done_at` is set to the current time, not the provided timestamp. 3. Repeat the update with the same payload, and observe `done_at` uses the provided timestamp. 4. Update a task with `{ "done": true }` only from undone state. 5. Observe that `done_at` is set to current time first, but changes to `"0001-01-01T00:00:00Z"` on repeated updates. Additional context: This behavior was observed on the API at https://try.vikunja.io/api/v1/tasks/{id} and /api/v1/tasks/bulk. Clarification on intended implementation of `done_at` handling when toggling task completion would be appreciated. ### Vikunja Version v1.0.0-rc1-125-a1e95789 ### Browser and version _No response_ ### Can you reproduce the bug on the Vikunja demo site? Yes ### Screenshots _No response_
GiteaMirror commented 2025-11-01 21:00:16 -05:00
Author
Owner
Copy Link

@kolaente commented on GitHub (Sep 11, 2025):

It should be possible to set this field to a user-supplied value. https://github.com/go-vikunja/vikunja/pull/1461 implements this properly.

@kolaente commented on GitHub (Sep 11, 2025): It should be possible to set this field to a user-supplied value. https://github.com/go-vikunja/vikunja/pull/1461 implements this properly.
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
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#607
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?