github-starred/vikunja
2
0
Fork 0
mirror of https://github.com/go-vikunja/vikunja.git synced 2026-03-09 07:13:35 -05:00
Code Issues 219 Packages Projects Releases 2 Wiki Activity

[SQLite] Users automatically deleted hour after 'vikunja restore' #117

New Issue
Closed
opened 2025-11-01 20:47:33 -05:00 by GiteaMirror · 2 comments
GiteaMirror commented 2025-11-01 20:47:33 -05:00
Owner
Copy Link

Originally created by @Frans-Willem on GitHub (Jan 4, 2023).

Description

Steps taken:

  • 'vikunja dump'
  • 'vikunja restore'
  • Wait until the next hour (e.g. ifit's 17:25, wait until 18:00)
  • Suddenly all users will be gone

After having done some digging, I believe this is done here:
a4c85fed55/pkg/models/user_delete.go (L46)

For some reason before doing a restore, 'SELECT * FROM Users WHERE deletion_scheduled_at NOT NULL;' returns no results, while after the restore it returns all users. Also, selecting for 'deletion_scheduled_at < time('now')' also returns the results:

sqlite> SELECT Username,deletion_scheduled_at FROM Users WHERE deletion_scheduled_at < time('now');
Frans-willem|

It appears that before the restore, the deletion_scheduled_at field contains NULL, whereas after the restore the field contains an empty string (''). It appears NULL is translated to "" in the dump JSON, which is then translated to '' when restoring...

Vikunja Frontend Version

N/A

Vikunja API Version

20.1

Browser and version

N/A

Can you reproduce the bug on the Vikunja demo site?

No

Screenshots

No response

Originally created by @Frans-Willem on GitHub (Jan 4, 2023). ### Description Steps taken: - 'vikunja dump' - 'vikunja restore' - Wait until the next hour (e.g. ifit's 17:25, wait until 18:00) - Suddenly all users will be gone After having done some digging, I believe this is done here: https://github.com/go-vikunja/api/blob/a4c85fed551acc9c1639ff35f76cf062a8cb2f1b/pkg/models/user_delete.go#L46 For some reason before doing a restore, 'SELECT * FROM Users WHERE deletion_scheduled_at NOT NULL;' returns no results, while after the restore it returns all users. Also, selecting for 'deletion_scheduled_at < time('now')' also returns the results: ``` sqlite> SELECT Username,deletion_scheduled_at FROM Users WHERE deletion_scheduled_at < time('now'); Frans-willem| ``` It appears that before the restore, the deletion_scheduled_at field contains NULL, whereas after the restore the field contains an empty string (''). It appears NULL is translated to "" in the dump JSON, which is then translated to '' when restoring... ### Vikunja Frontend Version N/A ### Vikunja API Version 20.1 ### Browser and version N/A ### Can you reproduce the bug on the Vikunja demo site? No ### Screenshots _No response_
GiteaMirror commented 2025-11-01 20:47:34 -05:00
Author
Owner
Copy Link

@Frans-Willem commented on GitHub (Jan 4, 2023):

Manually doing the following query in SQLite appears to be a possible band-aid:

sqlite> UPDATE Users SET deletion_scheduled_at = NULL WHERE deletion_scheduled_at = '';

Maybe a possible solution would be to iterate over all DATETIME fields in all tables after a restore and convert '' to NULL ?
I'm not sure why SQLite even allows empty strings as DATETIME :/

@Frans-Willem commented on GitHub (Jan 4, 2023): Manually doing the following query in SQLite appears to be a possible band-aid: ``` sqlite> UPDATE Users SET deletion_scheduled_at = NULL WHERE deletion_scheduled_at = ''; ``` Maybe a possible solution would be to iterate over all DATETIME fields in all tables after a restore and convert '' to NULL ? I'm not sure why SQLite even allows empty strings as DATETIME :/
GiteaMirror commented 2025-11-01 20:47:35 -05:00
Author
Owner
Copy Link

@kolaente commented on GitHub (Jan 5, 2023):

This has already been fixed in fbc4b91e0f. The fix does pretty much what you described in your second comment.

@kolaente commented on GitHub (Jan 5, 2023): This has already been fixed in fbc4b91e0f62f3639a5f9774f433fe3d8d7a8d23. The fix does pretty much what you described in your second comment.
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#117
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?