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

[GH-ISSUE #2188] Migration 0.24.6 -> 1.0.0 fails: All tasks orphaned (project_id=0) with SQLite + 2 top-level Projects #6584

New Issue
Closed
opened 2026-04-20 17:11:00 -05:00 by GiteaMirror · 3 comments
GiteaMirror commented 2026-04-20 17:11:00 -05:00
Owner
Copy Link

Originally created by @NixNivis on GitHub (Feb 2, 2026).
Original GitHub issue: https://github.com/go-vikunja/vikunja/issues/2188

Pre-submission checklist

  • I have searched for existing open or closed issue reports with the same problem.

Description

Description
After upgrading from Vikunja 0.24.6 to 1.0.0 (final release, not rc), all projects appear empty in the UI despite tasks and projects being present in the database.

Environment:
Vikunja version: 1.0.0 (upgraded from 0.24.6)

  • Database: SQLite
  • Installation method: .deb package on Debian Trixie
  • Original structure: 2 Projects, 16 Subprojects

What happens:

  1. Upgrade completes without migration errors
  2. Login successful
  3. UI (after login) shows empty state (no projects, no tasks visible)
  4. Creating new projects/tasks works fine, tasks are visible in "Upcoming"
  5. Creating any project makes them appear in "Overview"
  6. No task is linked to a Project created in 0.24.6. Web UI hangs when clicking "back to project" within any previously created task that was formerly attached to a project.

Database inspection reveals:

SELECT COUNT(*) FROM tasks;        -- 130 (all present)
SELECT COUNT(*) FROM projects;     -- 18 (2 projects + 16 subprojects)
SELECT COUNT(*) FROM tasks WHERE project_id IS NULL OR project_id = 0;  -- 130 (all orphaned!)

All 130 tasks have project_id = 0

Rollback: Rolling back to 0.24.6 restores all data successfully.

Similar issues:
#1341 (duplicate of #1339) reports similar symptoms for 1.0.0-rc1

This issue hints at a similar problem in 1.0.0 final.

Expected behavior:
Tasks should maintain their relationships during migration. Projects should be (re-)created in 1.0.0 in a similar structure (and be visible in WebUI).

Tested workarounds:

  • Config adjustments (absolute vs. relative database paths): No effect
  • Second upgrade attempt with corrected config: Same result

Vikunja Version

1.0.0

Browser and version

No response

Can you reproduce the bug on the Vikunja demo site?

No

Screenshots

No response

Originally created by @NixNivis on GitHub (Feb 2, 2026). Original GitHub issue: https://github.com/go-vikunja/vikunja/issues/2188 ### Pre-submission checklist - [x] I have searched for existing open or closed issue reports with the same problem. ### Description Description After upgrading from Vikunja 0.24.6 to 1.0.0 (final release, not rc), all projects appear empty in the UI despite tasks and projects being present in the database. Environment: Vikunja version: 1.0.0 (upgraded from 0.24.6) - Database: SQLite - Installation method: .deb package on Debian Trixie - Original structure: 2 Projects, 16 Subprojects What happens: 1. Upgrade completes without migration errors 2. Login successful 3. UI (after login) shows empty state (no projects, no tasks visible) 4. Creating new projects/tasks works fine, tasks are visible in "Upcoming" 5. Creating any project makes them appear in "Overview" 6. No task is linked to a Project created in 0.24.6. Web UI hangs when clicking "back to project" within any previously created task that was formerly attached to a project. Database inspection reveals: ```sql SELECT COUNT(*) FROM tasks; -- 130 (all present) SELECT COUNT(*) FROM projects; -- 18 (2 projects + 16 subprojects) SELECT COUNT(*) FROM tasks WHERE project_id IS NULL OR project_id = 0; -- 130 (all orphaned!) ``` All 130 tasks have project_id = 0 Rollback: Rolling back to 0.24.6 restores all data successfully. Similar issues: #1341 (duplicate of #1339) reports similar symptoms for 1.0.0-rc1 This issue hints at a similar problem in 1.0.0 final. Expected behavior: Tasks should maintain their relationships during migration. Projects should be (re-)created in 1.0.0 in a similar structure (and be visible in WebUI). Tested workarounds: - Config adjustments (absolute vs. relative database paths): No effect - Second upgrade attempt with corrected config: Same result ### Vikunja Version 1.0.0 ### Browser and version _No response_ ### Can you reproduce the bug on the Vikunja demo site? No ### Screenshots _No response_
GiteaMirror commented 2026-04-20 17:11:03 -05:00
Author
Owner
Copy Link

@NixNivis commented on GitHub (Feb 9, 2026):

Further testing with 1.1.0: The problem somewhat persists, there are no tasks visible in the initial view, changing to "Upcoming" shows all tasks, but orphaned.

New: As soon as I click a task and then click "back to project" the project reappears and the list on the left becomes populated, which then also shows all tasks that used to be in said project. However, this only works for subprojects from 0.24.6.

Clicking any task that used to be in one of the two (top level) projects and clicking "back to project" makes the WebUI hang and show "Internal Server Error" after a second.

(Behaviour in 1.0.0: clicking back to project made the WebUI hang indefinitely, until manuall reloading the page)

Possibly relevant error:

level=ERROR component=http method=GET uri=/api/v1/projects/4 status=500 latency=5.614114ms err="json: cannot unmarshal string into Go struct field ProjectViewBucketConfiguration.filter of type models.TaskCollection"
<!-- gh-comment-id:3872954149 --> @NixNivis commented on GitHub (Feb 9, 2026): Further testing with 1.1.0: The problem somewhat persists, there are no tasks visible in the initial view, changing to "Upcoming" shows all tasks, but orphaned. New: As soon as I click a task and then click "back to project" the project reappears and the list on the left becomes populated, which then also shows all tasks that used to be in said project. However, this only works for subprojects from 0.24.6. Clicking any task that used to be in one of the two (top level) projects and clicking "back to project" makes the WebUI hang and show "Internal Server Error" after a second. (Behaviour in 1.0.0: clicking back to project made the WebUI hang indefinitely, until manuall reloading the page) Possibly relevant error: ```bash level=ERROR component=http method=GET uri=/api/v1/projects/4 status=500 latency=5.614114ms err="json: cannot unmarshal string into Go struct field ProjectViewBucketConfiguration.filter of type models.TaskCollection" ```
GiteaMirror commented 2026-04-20 17:11:04 -05:00
Author
Owner
Copy Link

@NixNivis commented on GitHub (Feb 23, 2026):

Update: Successful upgrade to v1.1.0 with workaround

Managed to upgrade successfully by deleting all Kanban views before upgrading:

DELETE FROM project_views WHERE view_kind = 3;

After upgrade, all tasks were properly linked to projects. Kanban views can be recreated in the UI without issues.

CAVEAT:

  1. Merely deleting all Kanban views in the UI did not properly clean up all Kanban views according to a database query. All archived/deleted projects still had their Kanban view attached and one project (number 3) kept its Kanban view in the database despite being deleted in the UI.
  2. This workaround is probably not suited for people making extensive use of Kanban views already, because they have to be deleted and recreated.
<!-- gh-comment-id:3944779522 --> @NixNivis commented on GitHub (Feb 23, 2026): **Update: Successful upgrade to v1.1.0 with workaround** Managed to upgrade successfully by deleting all Kanban views before upgrading: ```sql DELETE FROM project_views WHERE view_kind = 3; ``` After upgrade, all tasks were properly linked to projects. Kanban views can be recreated in the UI without issues. CAVEAT: 1. Merely deleting all Kanban views in the UI did not properly clean up all Kanban views according to a database query. All archived/deleted projects still had their Kanban view attached and one project (number 3) kept its Kanban view in the database despite being deleted in the UI. 2. This workaround is probably not suited for people making extensive use of Kanban views already, because they have to be deleted and recreated.
GiteaMirror commented 2026-04-20 17:11:04 -05:00
Author
Owner
Copy Link

@vikunja-bot-app[bot] commented on GitHub (Feb 24, 2026):

This issue has been fixed in #2288, please check with the next unstable build (should be ready for deployment in ~30min, also on the demo).

<!-- gh-comment-id:3951859313 --> @vikunja-bot-app[bot] commented on GitHub (Feb 24, 2026): This issue has been fixed in #2288, please check with the next unstable build (should be ready for deployment in ~30min, also on [the demo](https://try.vikunja.io)).
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
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#6584
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?