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

Missing Data on Login after 0.24.6 - 1.0.0-rc1 upgrade #568

New Issue
Closed
opened 2025-11-01 20:59:23 -05:00 by GiteaMirror · 15 comments
GiteaMirror commented 2025-11-01 20:59:23 -05:00
Owner
Copy Link

Originally created by @chrismilson on GitHub (Aug 26, 2025).

Description

I recently upgraded from 0.24.6 to v1.0.0-rc1. Initially I had issues configuring oidc, as the schema had changed, and then I was getting Unauthorized errors post-login from the API until I set the VIKUNJA_SERVICE_PUBLICURL.

I have successfully logged in now, but the projects and tasks that I had created before the upgrade are now not visible. The account appears as if it were created new.

I have logged into the database and see that the original tasks and projects are still in the database in the expected tables. The tasks also appear to have the correct created_by_id as well.

When inspecting the users table, I do not see any new users - only the users that were there before.

If I try to create a new Project from the UI I can interact with it without issue. The entry for the new Project looks pretty much identical to the other entries in the table from before the upgrade though.

Vikunja Version

1.0.0-rc1

Browser and version

No response

Can you reproduce the bug on the Vikunja demo site?

No

Screenshots

No response

Originally created by @chrismilson on GitHub (Aug 26, 2025). ### Description I recently upgraded from 0.24.6 to v1.0.0-rc1. Initially I had issues configuring oidc, as the schema had changed, and then I was getting Unauthorized errors post-login from the API until I set the VIKUNJA_SERVICE_PUBLICURL. I have successfully logged in now, but the projects and tasks that I had created before the upgrade are now not visible. The account appears as if it were created new. I have logged into the database and see that the original tasks and projects are still in the database in the expected tables. The tasks also appear to have the correct created_by_id as well. When inspecting the users table, I do not see any new users - only the users that were there before. If I try to create a new Project from the UI I can interact with it without issue. The entry for the new Project looks pretty much identical to the other entries in the table from before the upgrade though. ### Vikunja Version 1.0.0-rc1 ### Browser and version _No response_ ### Can you reproduce the bug on the Vikunja demo site? No ### Screenshots _No response_
GiteaMirror commented 2025-11-01 20:59:24 -05:00
Author
Owner
Copy Link

@chrismilson commented on GitHub (Aug 26, 2025):

I was having trouble getting any meaningful logs too...

I sometimes see error messages like: "invalid character 'l' looking for beginning of value"

@chrismilson commented on GitHub (Aug 26, 2025): I was having trouble getting any meaningful logs too... I sometimes see error messages like: "invalid character 'l' looking for beginning of value"
GiteaMirror commented 2025-11-01 20:59:24 -05:00
Author
Owner
Copy Link

@fernandeusto commented on GitHub (Aug 26, 2025):

I also had to rollback to v0.24.6 — in version 1.0.0rc1 it doesn't have write permissions when you're already logged in, and it won't let you login if you're logged out.

@fernandeusto commented on GitHub (Aug 26, 2025): I also had to rollback to v0.24.6 — in version 1.0.0rc1 it doesn't have write permissions when you're already logged in, and it won't let you login if you're logged out.
GiteaMirror commented 2025-11-01 20:59:24 -05:00
Author
Owner
Copy Link

@fernandeusto commented on GitHub (Aug 27, 2025):

Solved in https://github.com/go-vikunja/vikunja/issues/1336

add enviroment: 'VIKUNJA_CORS_ENABLE: "false"' and it run OK with latest image

@fernandeusto commented on GitHub (Aug 27, 2025): Solved in https://github.com/go-vikunja/vikunja/issues/1336 add enviroment: 'VIKUNJA_CORS_ENABLE: "false"' and it run OK with latest image
GiteaMirror commented 2025-11-01 20:59:24 -05:00
Author
Owner
Copy Link

@kolaente commented on GitHub (Aug 29, 2025):

Can you verify that Vikunja is accessing the correct database?

@kolaente commented on GitHub (Aug 29, 2025): Can you verify that Vikunja is accessing the correct database?
GiteaMirror commented 2025-11-01 20:59:25 -05:00
Author
Owner
Copy Link

@chrismilson commented on GitHub (Aug 29, 2025):

Yep. From psql:

vikunja=# SELECT title, created FROM projects WHERE created > NOW() - INTERVAL '10 minutes';
    title     |       created       
--------------+---------------------
 test project | 2025-08-29 23:00:29
(1 row)

The rest of the projects I expect to see are in the table, but I can't see them in the UI. The entry in the projects table seems pretty much identical to the other entries there, but I'm not 100% sure how to see how these are expected to be associated with users etc. so can't comment on what might be looking weird in there.

@chrismilson commented on GitHub (Aug 29, 2025): Yep. From psql: ``` vikunja=# SELECT title, created FROM projects WHERE created > NOW() - INTERVAL '10 minutes'; title | created --------------+--------------------- test project | 2025-08-29 23:00:29 (1 row) ``` The rest of the projects I expect to see are in the table, but I can't see them in the UI. The entry in the projects table seems pretty much identical to the other entries there, but I'm not 100% sure how to see how these are expected to be associated with users etc. so can't comment on what might be looking weird in there.
GiteaMirror commented 2025-11-01 20:59:25 -05:00
Author
Owner
Copy Link

@chrismilson commented on GitHub (Aug 29, 2025):

Solved in #1336

add enviroment: 'VIKUNJA_CORS_ENABLE: "false"' and it run OK with latest image

I got around the CORS issue by setting the VIKUNJA_SERVICE_PUBLICURL to the base URL that the UI is hosted on. I put that in the initial description for context, sorry if it detracted from the actual issue, which appears to be related to the association of tasks/projects/etc. with users post migration from 0.24.6 to v1.

@chrismilson commented on GitHub (Aug 29, 2025): > Solved in [#1336](https://github.com/go-vikunja/vikunja/issues/1336) > > add enviroment: 'VIKUNJA_CORS_ENABLE: "false"' and it run OK with latest image I got around the CORS issue by setting the `VIKUNJA_SERVICE_PUBLICURL` to the base URL that the UI is hosted on. I put that in the initial description for context, sorry if it detracted from the actual issue, which appears to be related to the association of tasks/projects/etc. with users post migration from 0.24.6 to v1.
GiteaMirror commented 2025-11-01 20:59:25 -05:00
Author
Owner
Copy Link

@kolaente commented on GitHub (Aug 31, 2025):

Can you check the value of owner_id of your projects? The new and old created

@kolaente commented on GitHub (Aug 31, 2025): Can you check the value of `owner_id` of your projects? The new and old created
GiteaMirror commented 2025-11-01 20:59:26 -05:00
Author
Owner
Copy Link

@chrismilson commented on GitHub (Aug 31, 2025):

Looks to be consistent between the old and the new:

vikunja=# SELECT id, title, owner_id, created FROM projects WHERE id in (9, 29);
 id |    title     | owner_id |       created       
----+--------------+----------+---------------------
  9 | Homelab      |        2 | 2025-02-16 19:38:45
 29 | test project |        2 | 2025-08-31 15:15:03

The rest of the columns in the projects table seem to be pretty consistent, apart from a significantly different value for position. The old project's position is 65536, and the new is 1900544.

@chrismilson commented on GitHub (Aug 31, 2025): Looks to be consistent between the old and the new: ``` vikunja=# SELECT id, title, owner_id, created FROM projects WHERE id in (9, 29); id | title | owner_id | created ----+--------------+----------+--------------------- 9 | Homelab | 2 | 2025-02-16 19:38:45 29 | test project | 2 | 2025-08-31 15:15:03 ``` The rest of the columns in the `projects` table seem to be pretty consistent, apart from a significantly different value for `position`. The old project's position is 65536, and the new is 1900544.
GiteaMirror commented 2025-11-01 20:59:26 -05:00
Author
Owner
Copy Link

@kolaente commented on GitHub (Aug 31, 2025):

So the Homelab project is not visible, but the test project is? And none of the two are archived?

@kolaente commented on GitHub (Aug 31, 2025): So the `Homelab` project is not visible, but the `test project` is? And none of the two are archived?
GiteaMirror commented 2025-11-01 20:59:26 -05:00
Author
Owner
Copy Link

@chrismilson commented on GitHub (Aug 31, 2025):

Correct:

Image 
vikunja=# SELECT id, title, is_archived FROM projects WHERE id in (9, 29);
 id |    title     | is_archived 
----+--------------+-------------
  9 | Homelab      | f
 29 | test project | f
@chrismilson commented on GitHub (Aug 31, 2025): Correct: <img width="1250" height="510" alt="Image" src="https://github.com/user-attachments/assets/8f116997-f7ba-457b-b0ad-fa740e3de24f" /> ``` vikunja=# SELECT id, title, is_archived FROM projects WHERE id in (9, 29); id | title | is_archived ----+--------------+------------- 9 | Homelab | f 29 | test project | f ```
GiteaMirror commented 2025-11-01 20:59:26 -05:00
Author
Owner
Copy Link

@kolaente commented on GitHub (Aug 31, 2025):

Can you check with the browser network tools if all projects are returned from the request to /api/v1/projects?

@kolaente commented on GitHub (Aug 31, 2025): Can you check with the browser network tools if all projects are returned from the request to `/api/v1/projects`?
GiteaMirror commented 2025-11-01 20:59:27 -05:00
Author
Owner
Copy Link

@chrismilson commented on GitHub (Aug 31, 2025):

The browser makes a request to /api/v1/projects?is_archived=true&expand=permissions&page=1 and gets an HTTP500 response. Then it makes a specific request to /api/v1/projects/29. Now I'm wondering how the client even knows that 29 is the id of test project...

@chrismilson commented on GitHub (Aug 31, 2025): The browser makes a request to `/api/v1/projects?is_archived=true&expand=permissions&page=1` and gets an HTTP500 response. Then it makes a specific request to `/api/v1/projects/29`. Now I'm wondering how the client even knows that 29 is the id of `test project`...
GiteaMirror commented 2025-11-01 20:59:27 -05:00
Author
Owner
Copy Link

@kolaente commented on GitHub (Aug 31, 2025):

What's in the logs when the request with the 500 response happens?

@kolaente commented on GitHub (Aug 31, 2025): What's in the logs when the request with the 500 response happens?
GiteaMirror commented 2025-11-01 20:59:27 -05:00
Author
Owner
Copy Link

@chrismilson commented on GitHub (Aug 31, 2025):

Usually something like this:

time=2025-08-31T20:56:28.003Z level=ERROR msg="invalid character 'd' looking for beginning of value"
@chrismilson commented on GitHub (Aug 31, 2025): Usually something like this: ``` time=2025-08-31T20:56:28.003Z level=ERROR msg="invalid character 'd' looking for beginning of value" ```
GiteaMirror commented 2025-11-01 20:59:27 -05:00
Author
Owner
Copy Link

@kolaente commented on GitHub (Aug 31, 2025):

Then this is a duplicate of https://github.com/go-vikunja/vikunja/issues/1339

@kolaente commented on GitHub (Aug 31, 2025): Then this is a duplicate of https://github.com/go-vikunja/vikunja/issues/1339
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#568
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?