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 #2172] No data after upgrade to v1.0.0 #6574

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

Originally created by @freeware-superman on GitHub (Jan 28, 2026).
Original GitHub issue: https://github.com/go-vikunja/vikunja/issues/2172

Pre-submission checklist

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

Description

Hi,
congratulations on this huge milestone. The release notes for v1.0.0 made me really excited for the changes that have been in the making during the past couple of months.

When I tried to update form v0.24.6 though, I was greeted with a big problem: after login, all data was gone.
I was able to reproduce the behaviour with setup/data with the following steps:

  1. Have a running Vikunja v0.24.6 instance.
  2. Stop Docker compose stack
  3. Edit Docker compose to release tag v1.0.0 and edit SSO section in config.yml.
  4. Start stack

During the first login attempt, I get a message that an internal error occured. The second login attemt succeeds but all previous data (projects, teams, ToDos) are gone. However, having a look in my postgres database, all data is still there (as far as I can tell; regarding DBs I don't know that much).

My config:

Docker Compose 
services:
  vikunja:
    image: vikunja/vikunja:1.0.0
    container_name: vikunja
    depends_on:
      - vikunja_db
      - vikunja_redis
    environment:
      VIKUNJA_CACHE_ENABLED: true
      VIKUNJA_CACHE_TYPE: redis
      VIKUNJA_DATABASE_DATABASE: ${VIKUNJA_DB_NAME}
      VIKUNJA_DATABASE_HOST: vikunja_db
      VIKUNJA_DATABASE_PASSWORD: ${VIKUNJA_DB_PASSWORD}
      VIKUNJA_DATABASE_TYPE: postgres
      VIKUNJA_DATABASE_USER: ${VIKUNJA_DB_USER}
      VIKUNJA_REDIS_ENABLED: true
      VIKUNJA_REDIS_HOST: 'vikunja_redis:6379'
      VIKUNJA_SERVICE_JWTSECRET: ${VIKUNJA_JWSTSECRET}
      VIKUNJA_SERVICE_PUBLICURL: https://${VIKUNJA_URL}/
      VIKUNJA_LOG_LEVEL: "DEBUG"
    labels:
      - "traefik.docker.network=traefik_default"
      - "traefik.enable=true"
      - "traefik.http.routers.vikunja.entrypoints=websecure"
      - "traefik.http.routers.vikunja.rule=Host(`${VIKUNJA_URL}`)"
      - "traefik.http.routers.vikunja.tls.certResolver=le"
    networks:
      - backend
      - web
    restart: unless-stopped
    volumes:
      - ${STORAGE_PATH}/vikunja/app/config.yml:/app/vikunja/config.yml
      - ${STORAGE_PATH}/vikunja/app/files:/app/vikunja/files

  vikunja_db:
    image: postgres:18
    container_name: vikunja_db
    environment:
      POSTGRES_DB: ${VIKUNJA_DB_NAME}
      POSTGRES_PASSWORD: ${VIKUNJA_DB_PASSWORD}
      POSTGRES_USER: ${VIKUNJA_DB_USER}
    healthcheck:
      interval: 10s
      test: ["CMD-SHELL", "pg_isready -h localhost -U ${VIKUNJA_DB_USER}"]
    networks:
      - backend
    restart: unless-stopped
    volumes:
      - ${STORAGE_PATH}/vikunja/db-new:/var/lib/postgresql

  vikunja_redis:
    image: redis
    container_name: vikunja_redis
    networks:
      - backend
    restart: unless-stopped

networks:
  backend:
    external: false
    internal: true
    name: vikunja_backend
  web:
    external: true
    name: traefik_default
config.yml (partly redacted) 
auth:
  local:
    enabled: false
  openid:
    enabled: true
    redirecturl: [***]
    providers:
      [***]:
        name: [***]
        authurl: [***]
        logouturl: [***]
        clientid: [***]
        clientsecret: [***]

defaultsettings:
  discoverable_by_name: true
  week_start: 1
  default_project_id: 4
  email_reminders_enabled: true

cors:
  enable: false

service:
  timezone: 'Europe/Berlin'
  enableemailreminders: true

metrics:
  # If set to true, enables a /metrics endpoint for prometheus to collect metrics about Vikunja. You can query it from `/api/v1/metrics`.
  enabled: true
  # If set to a non-empty value the /metrics endpoint will require this as a username via basic auth in combination with the password below.
  username: [***]
  # If set to a non-empty value the /metrics endpoint will require this as a password via basic auth in combination with the username below.
  password: [***]

mailer:
  enabled: true
  host: [***]
  port: [***]
  authtype: 'login'
  username: [***]
  password: [***]
  fromemail: [***]

The logs

Vikunja log 
time=2026-01-28T03:21:27.978Z level=INFO msg="Using config file: /app/vikunja/config.yml"
time=2026-01-28T03:21:27.982Z level=DEBUG msg="Redis initialized"
time=2026-01-28T03:21:27.982Z level=INFO msg="Running migrations…"
time=2026-01-28T03:21:28.271Z level=INFO msg="Ran all migrations successfully."
time=2026-01-28T03:21:28.314Z level=DEBUG msg="[Task Reminder Cron] Timezone is Europe/Berlin"
time=2026-01-28T03:21:28.315Z level=INFO msg="Vikunja version v1.0.0"
time=2026-01-28T03:21:28.319Z level=DEBUG msg="Collecting 143 routes for API token usage"
time=2026-01-28T03:21:28.322Z level=INFO msg="HTTP server listening on :3456"
time=2026-01-28T03:22:00.000Z level=DEBUG msg="[Task Reminder Cron] Looking for reminders between 2026-01-28 04:22:00 +0100 CET nd 2026-01-28 04:23:00 +0100 CET to send..."
time=2026-01-28T03:22:00.015Z level=DEBUG msg="[Undone Overdue Tasks Reminder] Sending reminders to 0 users"
time=2026-01-28T03:22:00.016Z level=DEBUG msg="[Task Reminder Cron] Found 0 reminders"
time=2026-01-28T03:22:12.445Z level=DEBUG msg="Trying to authenticate user using provider: [***]"
time=2026-01-28T03:22:12.504Z level=DEBUG msg="Recalculating task positions for view 1"
time=2026-01-28T03:22:12.506Z level=ERROR msg="Error creating new user for provider [***]: pq: column tl.permission does not exist"
time=2026-01-28T03:22:39.046Z level=DEBUG msg="Trying to authenticate user using provider: [***]"
time=2026-01-28T03:22:39.058Z level=ERROR msg="Error retrieving token: oauth2: \"invalid_grant\" \"Code not valid\""
time=2026-01-28T03:22:39.058Z level=DEBUG msg="Raw token value is {\"error\":\"invalid_grant\",\"error_description\":\"Code not valid\"}"
time=2026-01-28T03:22:45.928Z level=DEBUG msg="Trying to authenticate user using provider: [***]"
time=2026-01-28T03:22:45.976Z level=ERROR msg="Error syncing avatar for user [***]: no picture URL provided"
time=2026-01-28T03:23:00.001Z level=DEBUG msg="[Task Reminder Cron] Looking for reminders between 2026-01-28 04:23:00 +0100 CET and 2026-01-28 04:24:00 +0100 CET to send..."
time=2026-01-28T03:23:00.013Z level=DEBUG msg="[Undone Overdue Tasks Reminder] Sending reminders to 0 users"
time=2026-01-28T03:23:00.013Z level=DEBUG msg="[Task Reminder Cron] Found 0 reminders"
time=2026-01-28T03:24:00.002Z level=DEBUG msg="[Task Reminder Cron] Looking for reminders between 2026-01-28 04:24:00 +0100 CET and 2026-01-28 04:25:00 +0100 CET to send..."
time=2026-01-28T03:24:00.015Z level=DEBUG msg="[Task Reminder Cron] Found 0 reminders"
time=2026-01-28T03:24:00.019Z level=DEBUG msg="[Undone Overdue Tasks Reminder] Sending reminders to 0 users"
...
Postgres log 
PostgreSQL Database directory appears to contain a database; Skipping initialization
2026-01-28 03:21:27.772 UTC [1] LOG:  starting PostgreSQL 18.1 (Debian 18.1-1.pgdg13+2) on x86_64-pc-linux-gnu, compiled by gcc (Debian 14.2.0-19) 14.2.0, 64-bit
2026-01-28 03:21:27.772 UTC [1] LOG:  listening on IPv4 address "0.0.0.0", port 5432
2026-01-28 03:21:27.772 UTC [1] LOG:  listening on IPv6 address "::", port 5432
2026-01-28 03:21:27.775 UTC [1] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2026-01-28 03:21:27.782 UTC [33] LOG:  database system was shut down at 2026-01-28 02:56:40 UTC
2026-01-28 03:21:27.826 UTC [1] LOG:  database system is ready to accept connections
2026-01-28 03:22:12.506 UTC [75] ERROR:  column tl.permission does not exist at character 722
2026-01-28 03:22:12.506 UTC [75] STATEMENT:  
	WITH RECURSIVE
	    project_hierarchy AS (
	        -- Base case: Start with the specified projects
	        SELECT id,
	               parent_project_id,
	               0  AS level,
	               id AS original_project_id
	        FROM projects
	        WHERE id IN (1)
	        UNION ALL
	        -- Recursive case: Traverse up the hierarchy
	        SELECT p.id,
	               p.parent_project_id,
	               ph.level + 1,
	               ph.original_project_id
	        FROM projects p
	                 INNER JOIN project_hierarchy ph ON p.id = ph.parent_project_id),
	    -- Calculate max team permission for each project/user combination
	    max_team_permissions AS (
	        SELECT tl.project_id,
	               MAX(tl.permission) AS max_team_permission
	        FROM team_projects tl
	                 INNER JOIN team_members tm ON tm.team_id = tl.team_id AND tm.user_id = $1
	        GROUP BY tl.project_id
	    ),
	    project_permissions AS (SELECT ph.id,
	                                   ph.original_project_id,
	                                   CASE
	                                       WHEN p.owner_id = $2 THEN 2
	                                       WHEN COALESCE(ul.permission, 0) > COALESCE(mtp.max_team_permission, 0) THEN ul.permission
	                                       ELSE COALESCE(mtp.max_team_permission, 0)
	                                       END AS project_permission,
	            CASE
	                WHEN p.owner_id = $3 THEN 1  -- Direct project ownership
	                ELSE ph.level + 1  -- Derived from parent project
	            END AS priority
	                            FROM project_hierarchy ph
	                                LEFT JOIN projects p
	                            ON ph.id = p.id
	                                LEFT JOIN users_projects ul ON ul.project_id = ph.id AND ul.user_id = $4
	                                LEFT JOIN max_team_permissions mtp ON mtp.project_id = ph.id
	                            WHERE p.owner_id = $5 OR ul.user_id = $6 OR mtp.max_team_permission IS NOT NULL)
	SELECT ph.original_project_id AS id,
	       COALESCE(MAX(pp.project_permission), -1) AS max_permission
	FROM project_hierarchy ph
	         LEFT JOIN (SELECT *,
	                           ROW_NUMBER() OVER (PARTITION BY original_project_id ORDER BY priority) AS rn
	                    FROM project_permissions) pp ON ph.id = pp.id AND pp.rn = 1
	GROUP BY ph.original_project_id
2026-01-28 03:22:46.139 UTC [102] ERROR:  column tl.permission does not exist at character 818
2026-01-28 03:22:46.139 UTC [102] STATEMENT:  
	WITH RECURSIVE
	    project_hierarchy AS (
	        -- Base case: Start with the specified projects
	        SELECT id,
	               parent_project_id,
	               0  AS level,
	               id AS original_project_id
	        FROM projects
	        WHERE id IN (9, 18, 180, 1, 126, 8, 35, 4, 37, 40, 28, 29, 36, 41, 42, 53, 109, 127, 7, 185, 197, 5, 21, 6, 10)
	        UNION ALL
	        -- Recursive case: Traverse up the hierarchy
	        SELECT p.id,
	               p.parent_project_id,
	               ph.level + 1,
	               ph.original_project_id
	        FROM projects p
	                 INNER JOIN project_hierarchy ph ON p.id = ph.parent_project_id),
	    -- Calculate max team permission for each project/user combination
	    max_team_permissions AS (
	        SELECT tl.project_id,
	               MAX(tl.permission) AS max_team_permission
	        FROM team_projects tl
	                 INNER JOIN team_members tm ON tm.team_id = tl.team_id AND tm.user_id = $1
	        GROUP BY tl.project_id
	    ),
	    project_permissions AS (SELECT ph.id,
	                                   ph.original_project_id,
	                                   CASE
	                                       WHEN p.owner_id = $2 THEN 2
	                                       WHEN COALESCE(ul.permission, 0) > COALESCE(mtp.max_team_permission, 0) THEN ul.permission
	                                       ELSE COALESCE(mtp.max_team_permission, 0)
	                                       END AS project_permission,
	            CASE
	                WHEN p.owner_id = $3 THEN 1  -- Direct project ownership
	                ELSE ph.level + 1  -- Derived from parent project
	            END AS priority
	                            FROM project_hierarchy ph
	                                LEFT JOIN projects p
	                            ON ph.id = p.id
	                                LEFT JOIN users_projects ul ON ul.project_id = ph.id AND ul.user_id = $4
	                                LEFT JOIN max_team_permissions mtp ON mtp.project_id = ph.id
	                            WHERE p.owner_id = $5 OR ul.user_id = $6 OR mtp.max_team_permission IS NOT NULL)
	SELECT ph.original_project_id AS id,
	       COALESCE(MAX(pp.project_permission), -1) AS max_permission
	FROM project_hierarchy ph
	         LEFT JOIN (SELECT *,
	                           ROW_NUMBER() OVER (PARTITION BY original_project_id ORDER BY priority) AS rn
	                    FROM project_permissions) pp ON ph.id = pp.id AND pp.rn = 1
	GROUP BY ph.original_project_id

Is there anything I missed for the upgrade? If not, I'd be happy to help as good as I can.

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 @freeware-superman on GitHub (Jan 28, 2026). Original GitHub issue: https://github.com/go-vikunja/vikunja/issues/2172 ### Pre-submission checklist - [x] I have searched for existing open or closed issue reports with the same problem. ### Description Hi, congratulations on this huge milestone. The release notes for v1.0.0 made me really excited for the changes that have been in the making during the past couple of months. When I tried to update form v0.24.6 though, I was greeted with a big problem: after login, all data was gone. I was able to reproduce the behaviour with setup/data with the following steps: 1. Have a running Vikunja v0.24.6 instance. 2. Stop Docker compose stack 3. Edit Docker compose to release tag v1.0.0 and edit SSO section in `config.yml`. 4. Start stack During the first login attempt, I get a message that an internal error occured. The second login attemt succeeds but all previous data (projects, teams, ToDos) are gone. However, having a look in my postgres database, all data is still there (as far as I can tell; regarding DBs I don't know that much). --- ### My config: <details> <summary>Docker Compose</summary> ``` yml services: vikunja: image: vikunja/vikunja:1.0.0 container_name: vikunja depends_on: - vikunja_db - vikunja_redis environment: VIKUNJA_CACHE_ENABLED: true VIKUNJA_CACHE_TYPE: redis VIKUNJA_DATABASE_DATABASE: ${VIKUNJA_DB_NAME} VIKUNJA_DATABASE_HOST: vikunja_db VIKUNJA_DATABASE_PASSWORD: ${VIKUNJA_DB_PASSWORD} VIKUNJA_DATABASE_TYPE: postgres VIKUNJA_DATABASE_USER: ${VIKUNJA_DB_USER} VIKUNJA_REDIS_ENABLED: true VIKUNJA_REDIS_HOST: 'vikunja_redis:6379' VIKUNJA_SERVICE_JWTSECRET: ${VIKUNJA_JWSTSECRET} VIKUNJA_SERVICE_PUBLICURL: https://${VIKUNJA_URL}/ VIKUNJA_LOG_LEVEL: "DEBUG" labels: - "traefik.docker.network=traefik_default" - "traefik.enable=true" - "traefik.http.routers.vikunja.entrypoints=websecure" - "traefik.http.routers.vikunja.rule=Host(`${VIKUNJA_URL}`)" - "traefik.http.routers.vikunja.tls.certResolver=le" networks: - backend - web restart: unless-stopped volumes: - ${STORAGE_PATH}/vikunja/app/config.yml:/app/vikunja/config.yml - ${STORAGE_PATH}/vikunja/app/files:/app/vikunja/files vikunja_db: image: postgres:18 container_name: vikunja_db environment: POSTGRES_DB: ${VIKUNJA_DB_NAME} POSTGRES_PASSWORD: ${VIKUNJA_DB_PASSWORD} POSTGRES_USER: ${VIKUNJA_DB_USER} healthcheck: interval: 10s test: ["CMD-SHELL", "pg_isready -h localhost -U ${VIKUNJA_DB_USER}"] networks: - backend restart: unless-stopped volumes: - ${STORAGE_PATH}/vikunja/db-new:/var/lib/postgresql vikunja_redis: image: redis container_name: vikunja_redis networks: - backend restart: unless-stopped networks: backend: external: false internal: true name: vikunja_backend web: external: true name: traefik_default ``` </details> <details> <summary>config.yml (partly redacted)</summary> ``` yml auth: local: enabled: false openid: enabled: true redirecturl: [***] providers: [***]: name: [***] authurl: [***] logouturl: [***] clientid: [***] clientsecret: [***] defaultsettings: discoverable_by_name: true week_start: 1 default_project_id: 4 email_reminders_enabled: true cors: enable: false service: timezone: 'Europe/Berlin' enableemailreminders: true metrics: # If set to true, enables a /metrics endpoint for prometheus to collect metrics about Vikunja. You can query it from `/api/v1/metrics`. enabled: true # If set to a non-empty value the /metrics endpoint will require this as a username via basic auth in combination with the password below. username: [***] # If set to a non-empty value the /metrics endpoint will require this as a password via basic auth in combination with the username below. password: [***] mailer: enabled: true host: [***] port: [***] authtype: 'login' username: [***] password: [***] fromemail: [***] ``` </details> --- ### The logs <details> <summary>Vikunja log</summary> ``` time=2026-01-28T03:21:27.978Z level=INFO msg="Using config file: /app/vikunja/config.yml" time=2026-01-28T03:21:27.982Z level=DEBUG msg="Redis initialized" time=2026-01-28T03:21:27.982Z level=INFO msg="Running migrations…" time=2026-01-28T03:21:28.271Z level=INFO msg="Ran all migrations successfully." time=2026-01-28T03:21:28.314Z level=DEBUG msg="[Task Reminder Cron] Timezone is Europe/Berlin" time=2026-01-28T03:21:28.315Z level=INFO msg="Vikunja version v1.0.0" time=2026-01-28T03:21:28.319Z level=DEBUG msg="Collecting 143 routes for API token usage" time=2026-01-28T03:21:28.322Z level=INFO msg="HTTP server listening on :3456" time=2026-01-28T03:22:00.000Z level=DEBUG msg="[Task Reminder Cron] Looking for reminders between 2026-01-28 04:22:00 +0100 CET nd 2026-01-28 04:23:00 +0100 CET to send..." time=2026-01-28T03:22:00.015Z level=DEBUG msg="[Undone Overdue Tasks Reminder] Sending reminders to 0 users" time=2026-01-28T03:22:00.016Z level=DEBUG msg="[Task Reminder Cron] Found 0 reminders" time=2026-01-28T03:22:12.445Z level=DEBUG msg="Trying to authenticate user using provider: [***]" time=2026-01-28T03:22:12.504Z level=DEBUG msg="Recalculating task positions for view 1" time=2026-01-28T03:22:12.506Z level=ERROR msg="Error creating new user for provider [***]: pq: column tl.permission does not exist" time=2026-01-28T03:22:39.046Z level=DEBUG msg="Trying to authenticate user using provider: [***]" time=2026-01-28T03:22:39.058Z level=ERROR msg="Error retrieving token: oauth2: \"invalid_grant\" \"Code not valid\"" time=2026-01-28T03:22:39.058Z level=DEBUG msg="Raw token value is {\"error\":\"invalid_grant\",\"error_description\":\"Code not valid\"}" time=2026-01-28T03:22:45.928Z level=DEBUG msg="Trying to authenticate user using provider: [***]" time=2026-01-28T03:22:45.976Z level=ERROR msg="Error syncing avatar for user [***]: no picture URL provided" time=2026-01-28T03:23:00.001Z level=DEBUG msg="[Task Reminder Cron] Looking for reminders between 2026-01-28 04:23:00 +0100 CET and 2026-01-28 04:24:00 +0100 CET to send..." time=2026-01-28T03:23:00.013Z level=DEBUG msg="[Undone Overdue Tasks Reminder] Sending reminders to 0 users" time=2026-01-28T03:23:00.013Z level=DEBUG msg="[Task Reminder Cron] Found 0 reminders" time=2026-01-28T03:24:00.002Z level=DEBUG msg="[Task Reminder Cron] Looking for reminders between 2026-01-28 04:24:00 +0100 CET and 2026-01-28 04:25:00 +0100 CET to send..." time=2026-01-28T03:24:00.015Z level=DEBUG msg="[Task Reminder Cron] Found 0 reminders" time=2026-01-28T03:24:00.019Z level=DEBUG msg="[Undone Overdue Tasks Reminder] Sending reminders to 0 users" ... ``` </details> <details> <summary>Postgres log</summary> ``` log PostgreSQL Database directory appears to contain a database; Skipping initialization 2026-01-28 03:21:27.772 UTC [1] LOG: starting PostgreSQL 18.1 (Debian 18.1-1.pgdg13+2) on x86_64-pc-linux-gnu, compiled by gcc (Debian 14.2.0-19) 14.2.0, 64-bit 2026-01-28 03:21:27.772 UTC [1] LOG: listening on IPv4 address "0.0.0.0", port 5432 2026-01-28 03:21:27.772 UTC [1] LOG: listening on IPv6 address "::", port 5432 2026-01-28 03:21:27.775 UTC [1] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432" 2026-01-28 03:21:27.782 UTC [33] LOG: database system was shut down at 2026-01-28 02:56:40 UTC 2026-01-28 03:21:27.826 UTC [1] LOG: database system is ready to accept connections 2026-01-28 03:22:12.506 UTC [75] ERROR: column tl.permission does not exist at character 722 2026-01-28 03:22:12.506 UTC [75] STATEMENT: WITH RECURSIVE project_hierarchy AS ( -- Base case: Start with the specified projects SELECT id, parent_project_id, 0 AS level, id AS original_project_id FROM projects WHERE id IN (1) UNION ALL -- Recursive case: Traverse up the hierarchy SELECT p.id, p.parent_project_id, ph.level + 1, ph.original_project_id FROM projects p INNER JOIN project_hierarchy ph ON p.id = ph.parent_project_id), -- Calculate max team permission for each project/user combination max_team_permissions AS ( SELECT tl.project_id, MAX(tl.permission) AS max_team_permission FROM team_projects tl INNER JOIN team_members tm ON tm.team_id = tl.team_id AND tm.user_id = $1 GROUP BY tl.project_id ), project_permissions AS (SELECT ph.id, ph.original_project_id, CASE WHEN p.owner_id = $2 THEN 2 WHEN COALESCE(ul.permission, 0) > COALESCE(mtp.max_team_permission, 0) THEN ul.permission ELSE COALESCE(mtp.max_team_permission, 0) END AS project_permission, CASE WHEN p.owner_id = $3 THEN 1 -- Direct project ownership ELSE ph.level + 1 -- Derived from parent project END AS priority FROM project_hierarchy ph LEFT JOIN projects p ON ph.id = p.id LEFT JOIN users_projects ul ON ul.project_id = ph.id AND ul.user_id = $4 LEFT JOIN max_team_permissions mtp ON mtp.project_id = ph.id WHERE p.owner_id = $5 OR ul.user_id = $6 OR mtp.max_team_permission IS NOT NULL) SELECT ph.original_project_id AS id, COALESCE(MAX(pp.project_permission), -1) AS max_permission FROM project_hierarchy ph LEFT JOIN (SELECT *, ROW_NUMBER() OVER (PARTITION BY original_project_id ORDER BY priority) AS rn FROM project_permissions) pp ON ph.id = pp.id AND pp.rn = 1 GROUP BY ph.original_project_id 2026-01-28 03:22:46.139 UTC [102] ERROR: column tl.permission does not exist at character 818 2026-01-28 03:22:46.139 UTC [102] STATEMENT: WITH RECURSIVE project_hierarchy AS ( -- Base case: Start with the specified projects SELECT id, parent_project_id, 0 AS level, id AS original_project_id FROM projects WHERE id IN (9, 18, 180, 1, 126, 8, 35, 4, 37, 40, 28, 29, 36, 41, 42, 53, 109, 127, 7, 185, 197, 5, 21, 6, 10) UNION ALL -- Recursive case: Traverse up the hierarchy SELECT p.id, p.parent_project_id, ph.level + 1, ph.original_project_id FROM projects p INNER JOIN project_hierarchy ph ON p.id = ph.parent_project_id), -- Calculate max team permission for each project/user combination max_team_permissions AS ( SELECT tl.project_id, MAX(tl.permission) AS max_team_permission FROM team_projects tl INNER JOIN team_members tm ON tm.team_id = tl.team_id AND tm.user_id = $1 GROUP BY tl.project_id ), project_permissions AS (SELECT ph.id, ph.original_project_id, CASE WHEN p.owner_id = $2 THEN 2 WHEN COALESCE(ul.permission, 0) > COALESCE(mtp.max_team_permission, 0) THEN ul.permission ELSE COALESCE(mtp.max_team_permission, 0) END AS project_permission, CASE WHEN p.owner_id = $3 THEN 1 -- Direct project ownership ELSE ph.level + 1 -- Derived from parent project END AS priority FROM project_hierarchy ph LEFT JOIN projects p ON ph.id = p.id LEFT JOIN users_projects ul ON ul.project_id = ph.id AND ul.user_id = $4 LEFT JOIN max_team_permissions mtp ON mtp.project_id = ph.id WHERE p.owner_id = $5 OR ul.user_id = $6 OR mtp.max_team_permission IS NOT NULL) SELECT ph.original_project_id AS id, COALESCE(MAX(pp.project_permission), -1) AS max_permission FROM project_hierarchy ph LEFT JOIN (SELECT *, ROW_NUMBER() OVER (PARTITION BY original_project_id ORDER BY priority) AS rn FROM project_permissions) pp ON ph.id = pp.id AND pp.rn = 1 GROUP BY ph.original_project_id ``` </details> --- Is there anything I missed for the upgrade? If not, I'd be happy to help as good as I can. ### 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:10:16 -05:00
Author
Owner
Copy Link

@SamBouwer commented on GitHub (Jan 28, 2026):

I have the exact same starting situation/state, same changes (SSO config change and image tag update) and the same outcome (no projects, no tasks, but for example labels are present) but with a different error:

Vikunja | 2026-01-28T21:15:44.852729097Z time=2026-01-28T21:15:44.852Z level=ERROR component=http method=GET uri="/api/v1/projects?is_archived=true&expand=permissions&page=1" status=500 latency=20.489701ms err="json: cannot unmarshal string into Go struct field ProjectViewBucketConfiguration.filter of type models.TaskCollection"

I am able to get to a specific task by manually going to a task URL: https://[my.vikunja.instance]/tasks/53 does show the task details!

I made a backup, but I'm also able to get everything back to working by reverting the SSO config change and reverting back to the 0.24.6 tag. Therefore, it feels like the database migrations that are needed are not actually done?

<!-- gh-comment-id:3813976165 --> @SamBouwer commented on GitHub (Jan 28, 2026): I have the exact same starting situation/state, same changes (SSO config change and image tag update) and the same outcome (no projects, no tasks, but for example labels are present) but with a different error: `Vikunja | 2026-01-28T21:15:44.852729097Z time=2026-01-28T21:15:44.852Z level=ERROR component=http method=GET uri="/api/v1/projects?is_archived=true&expand=permissions&page=1" status=500 latency=20.489701ms err="json: cannot unmarshal string into Go struct field ProjectViewBucketConfiguration.filter of type models.TaskCollection"` I am able to get to a specific task by manually going to a task URL: https://[my.vikunja.instance]/tasks/53 does show the task details! I made a backup, but I'm also able to get everything back to working by reverting the SSO config change and reverting back to the 0.24.6 tag. Therefore, it feels like the database migrations that are needed are not actually done?
GiteaMirror commented 2026-04-20 17:10:16 -05:00
Author
Owner
Copy Link

@kolaente commented on GitHub (Jan 28, 2026):

Can you check how many users you have in the users table in the db? I suspect that your user was not mapped to the existing one and you got a new one created (which won't have the data of the older one)

<!-- gh-comment-id:3814081032 --> @kolaente commented on GitHub (Jan 28, 2026): Can you check how many users you have in the `users` table in the db? I suspect that your user was not mapped to the existing one and you got a new one created (which won't have the data of the older one)
GiteaMirror commented 2026-04-20 17:10:17 -05:00
Author
Owner
Copy Link

@SamBouwer commented on GitHub (Jan 28, 2026):

I have 9 users, which is the expected amount (same as before upgrade to 1.0.0). Not sure if that is relevant for "my" error. Let me know if you suspect the issues are different, then I can create a separate issue.

<!-- gh-comment-id:3814095380 --> @SamBouwer commented on GitHub (Jan 28, 2026): I have 9 users, which is the expected amount (same as before upgrade to 1.0.0). Not sure if that is relevant for "my" error. Let me know if you suspect the issues are different, then I can create a separate issue.
GiteaMirror commented 2026-04-20 17:10:17 -05:00
Author
Owner
Copy Link

@kolaente commented on GitHub (Jan 28, 2026):

It could also be a missing migration. Can you post the content of the migrations table?

<!-- gh-comment-id:3814145277 --> @kolaente commented on GitHub (Jan 28, 2026): It could also be a missing migration. Can you post the content of the `migrations` table?
GiteaMirror commented 2026-04-20 17:10:18 -05:00
Author
Owner
Copy Link

@SamBouwer commented on GitHub (Jan 28, 2026):

Sure! Here you go:

Edit: I double checked and the "SCHEMA_INIT" indeed appears twice in the migration table

       id       | description 
----------------+-------------
 SCHEMA_INIT    | 
 20190324205606 | 
 20190328074430 | 
 20190430111111 | 
 20190511202210 | 
 20190514192749 | 
 20190524205441 | 
 20190718200716 | 
 20190818210133 | 
 20190920185205 | 
 20190922205826 | 
 20191008194238 | 
 20191010131430 | 
 20191207204427 | 
 20191207220736 | 
 20200120201756 | 
 20200219183248 | 
 20200308205855 | 
 20200308210130 | 
 20200322214440 | 
 20200322214624 | 
 20200417175201 | 
 20200418230432 | 
 20200418230605 | 
 20200420215928 | 
 20200425182634 | 
 20200509103709 | 
 20200515172220 | 
 20200515195546 | 
 20200516123847 | 
 20200524221534 | 
 20200524224611 | 
 20200614113230 | 
 20200621214452 | 
 20200801183357 | 
 20200904101559 | 
 20200905151040 | 
 20200905232458 | 
 20200906184746 | 
 20201025195822 | 
 20201121181647 | 
 20201218152741 | 
 20201218220204 | 
 20201219145028 | 
 20210207192805 | 
 20210209204715 | 
 20210220222121 | 
 20210221111953 | 
 20210321185225 | 
 20210328191017 | 
 20210403145503 | 
 20210403220653 | 
 20210407170753 | 
 20210411113105 | 
 20210411161337 | 
 20210413131057 | 
 20210527105701 | 
 20210603174608 | 
 20210709191101 | 
 20210709211508 | 
 20210711173657 | 
 20210713213622 | 
 20210725153703 | 
 20210727204942 | 
 20210727211037 | 
 20210729142940 | 
 20210802081716 | 
 20210829194722 | 
 20211212151642 | 
 20211212210054 | 
 20220112211537 | 
 20220616145228 | 
 20220815200851 |
 20221002120521 | 
 20221113170740 | 
 20221228112131 | 
 20230104152903 | 
 20230307171848 | 
 20230611170341 | 
 20230824132533 | 
 20230828125443 | 
 20230831155832 | 
 20230903143017 | 
 20230913202615 | 
 20231022144641 | 
 20231108231513 | 
 20231121191822 | 
 20240114224713 | 
 20240304153738 | 
 20240309111148 | 
 20240311173251 | 
 20240313230538 | 
 20240314214802 | 
 20240315093418 | 
 20240315104205 | 
 20240315110428 | 
 20240329170952 | 
 20240406125227 | 
 20240603172746 | 
 20240919130957 | 
 20241028131622 | 
 20241118123644 | 
 20241119115012 | 
 20250317174522 | 
 20250323212553 | 
 20250402173109 | 
 20250624092830 | 
 20250813093602 | 
 SCHEMA_INIT    | 
 20190324205606 | 
 20190328074430 | 
 20190430111111 | 
 20190511202210 | 
 20190514192749 | 
 20190524205441 | 
 20190718200716 | 
 20190818210133 | 
 20190920185205 | 
 20190922205826 | 
 20191008194238 | 
 20191010131430 | 
 20191207204427 | 
 20191207220736 | 
 20200120201756 | 
 20200219183248 | 
 20200308205855 | 
 20200308210130 | 
 20200322214440 | 
 20200322214624 | 
 20200417175201 | 
 20200418230432 | 
 20200418230605 | 
 20200420215928 | 
 20200425182634 | 
 20200509103709 | 
 20200515172220 | 
 20200515195546 | 
 20200516123847 | 
 20200524221534 | 
 20200524224611 | 
 20200614113230 | 
 20200621214452 | 
 20200801183357 | 
 20200904101559 | 
 20200905151040 | 
 20200905232458 | 
 20200906184746 | 
 20201025195822 | 
 20201121181647 | 
 20201218152741 | 
 20201218220204 | 
 20201219145028 | 
 20210207192805 | 
 20210209204715 | 
 20210220222121 | 
 20210221111953 | 
 20210321185225 | 
 20210328191017 | 
 20210403145503 | 
 20210403220653 | 
 20210407170753 | 
 20210411113105 | 
 20210411161337 | 
 20210413131057 | 
 20210527105701 | 
 20210603174608 | 
 20210709191101 | 
 20210709211508 | 
 20210711173657 | 
 20210713213622 | 
 20210725153703 | 
 20210727204942 | 
 20210727211037 | 
 20210729142940 | 
 20210802081716 | 
 20210829194722 | 
 20211212151642 | 
 20211212210054 | 
 20220112211537 | 
 20220616145228 | 
 20220815200851 | 
 20221002120521 | 
 20221113170740 | 
 20221228112131 | 
 20230104152903 | 
 20230307171848 | 
 20230611170341 | 
 20230824132533 | 
 20230828125443 | 
 20230831155832 | 
 20230903143017 | 
 20230913202615 | 
 20231022144641 | 
 20231108231513 | 
 20231121191822 | 
 20240114224713 | 
 20240304153738 | 
 20240309111148 | 
 20240311173251 | 
 20240313230538 | 
 20240314214802 | 
 20240315093418 | 
 20240315104205 | 
 20240315110428 | 
 20240329170952 | 
 20240406125227 | 
 20240603172746 | 
 20240919130957 | 
 20241028131622 | 
 20241118123644 | 
 20241119115012 | 
 20250317174522 | 
 20250323212553 | 
 20250402173109 | 
 20250624092830 | 
 20250813093602 | 
 20251001113831 | 
 20251108154913 | 
 20251118125156 | 
 (219 rows)

(END)
<!-- gh-comment-id:3814248921 --> @SamBouwer commented on GitHub (Jan 28, 2026): Sure! Here you go: Edit: I double checked and the "SCHEMA_INIT" indeed appears twice in the `migration` table ```SQL id | description ----------------+------------- SCHEMA_INIT | 20190324205606 | 20190328074430 | 20190430111111 | 20190511202210 | 20190514192749 | 20190524205441 | 20190718200716 | 20190818210133 | 20190920185205 | 20190922205826 | 20191008194238 | 20191010131430 | 20191207204427 | 20191207220736 | 20200120201756 | 20200219183248 | 20200308205855 | 20200308210130 | 20200322214440 | 20200322214624 | 20200417175201 | 20200418230432 | 20200418230605 | 20200420215928 | 20200425182634 | 20200509103709 | 20200515172220 | 20200515195546 | 20200516123847 | 20200524221534 | 20200524224611 | 20200614113230 | 20200621214452 | 20200801183357 | 20200904101559 | 20200905151040 | 20200905232458 | 20200906184746 | 20201025195822 | 20201121181647 | 20201218152741 | 20201218220204 | 20201219145028 | 20210207192805 | 20210209204715 | 20210220222121 | 20210221111953 | 20210321185225 | 20210328191017 | 20210403145503 | 20210403220653 | 20210407170753 | 20210411113105 | 20210411161337 | 20210413131057 | 20210527105701 | 20210603174608 | 20210709191101 | 20210709211508 | 20210711173657 | 20210713213622 | 20210725153703 | 20210727204942 | 20210727211037 | 20210729142940 | 20210802081716 | 20210829194722 | 20211212151642 | 20211212210054 | 20220112211537 | 20220616145228 | 20220815200851 | 20221002120521 | 20221113170740 | 20221228112131 | 20230104152903 | 20230307171848 | 20230611170341 | 20230824132533 | 20230828125443 | 20230831155832 | 20230903143017 | 20230913202615 | 20231022144641 | 20231108231513 | 20231121191822 | 20240114224713 | 20240304153738 | 20240309111148 | 20240311173251 | 20240313230538 | 20240314214802 | 20240315093418 | 20240315104205 | 20240315110428 | 20240329170952 | 20240406125227 | 20240603172746 | 20240919130957 | 20241028131622 | 20241118123644 | 20241119115012 | 20250317174522 | 20250323212553 | 20250402173109 | 20250624092830 | 20250813093602 | SCHEMA_INIT | 20190324205606 | 20190328074430 | 20190430111111 | 20190511202210 | 20190514192749 | 20190524205441 | 20190718200716 | 20190818210133 | 20190920185205 | 20190922205826 | 20191008194238 | 20191010131430 | 20191207204427 | 20191207220736 | 20200120201756 | 20200219183248 | 20200308205855 | 20200308210130 | 20200322214440 | 20200322214624 | 20200417175201 | 20200418230432 | 20200418230605 | 20200420215928 | 20200425182634 | 20200509103709 | 20200515172220 | 20200515195546 | 20200516123847 | 20200524221534 | 20200524224611 | 20200614113230 | 20200621214452 | 20200801183357 | 20200904101559 | 20200905151040 | 20200905232458 | 20200906184746 | 20201025195822 | 20201121181647 | 20201218152741 | 20201218220204 | 20201219145028 | 20210207192805 | 20210209204715 | 20210220222121 | 20210221111953 | 20210321185225 | 20210328191017 | 20210403145503 | 20210403220653 | 20210407170753 | 20210411113105 | 20210411161337 | 20210413131057 | 20210527105701 | 20210603174608 | 20210709191101 | 20210709211508 | 20210711173657 | 20210713213622 | 20210725153703 | 20210727204942 | 20210727211037 | 20210729142940 | 20210802081716 | 20210829194722 | 20211212151642 | 20211212210054 | 20220112211537 | 20220616145228 | 20220815200851 | 20221002120521 | 20221113170740 | 20221228112131 | 20230104152903 | 20230307171848 | 20230611170341 | 20230824132533 | 20230828125443 | 20230831155832 | 20230903143017 | 20230913202615 | 20231022144641 | 20231108231513 | 20231121191822 | 20240114224713 | 20240304153738 | 20240309111148 | 20240311173251 | 20240313230538 | 20240314214802 | 20240315093418 | 20240315104205 | 20240315110428 | 20240329170952 | 20240406125227 | 20240603172746 | 20240919130957 | 20241028131622 | 20241118123644 | 20241119115012 | 20250317174522 | 20250323212553 | 20250402173109 | 20250624092830 | 20250813093602 | 20251001113831 | 20251108154913 | 20251118125156 | (219 rows) (END) ```
GiteaMirror commented 2026-04-20 17:10:19 -05:00
Author
Owner
Copy Link

@SamBouwer commented on GitHub (Jan 28, 2026):

I found the issue (I hope 👼 )!

In the bucket_configuration column in the project_views table I had one record of a Kanban view with value

[{"title":"Wachtend op VBA","filter":"labels = 1"},{"title":"Backlog","filter":"done = false"}]

All other records either had null or [] as value for that column. Everything seems fine again after replacing that value for that record using this command:

update project_views set bucket_configuration = '[]' where id = 12;

I'll report back if I find something not working.

<!-- gh-comment-id:3814303530 --> @SamBouwer commented on GitHub (Jan 28, 2026): I found the issue (I hope 👼 )! In the `bucket_configuration` column in the `project_views` table I had one record of a Kanban view with value `[{"title":"Wachtend op VBA","filter":"labels = 1"},{"title":"Backlog","filter":"done = false"}]` All other records either had `null` or `[]` as value for that column. Everything seems fine again after replacing that value for that record using this command: `update project_views set bucket_configuration = '[]' where id = 12;` I'll report back if I find something not working.
GiteaMirror commented 2026-04-20 17:10:19 -05:00
Author
Owner
Copy Link

@freeware-superman commented on GitHub (Jan 29, 2026):

In all three cases (before migration and after migration before the first login attempt and after successful login) I have the same amount of entries in users. The table entry for the user that tried to login does not change. But it also does not update when changing any user setting in the web interface.

In contrast to @SamBouwer's migration table, I'm missing all entries after 20240919130957. Furthermore, I also only have one SCHEMA_INIT entry.

Output from "SELECT * FROM migration;" 
       id       | description 
----------------+-------------
 SCHEMA_INIT    | 
 20190324205606 | 
 20190328074430 | 
 20190430111111 | 
 20190511202210 | 
 20190514192749 | 
 20190524205441 | 
 20190718200716 | 
 20190818210133 | 
 20190920185205 | 
 20190922205826 | 
 20191008194238 | 
 20191010131430 | 
 20191207204427 | 
 20191207220736 | 
 20200120201756 | 
 20200219183248 | 
 20200308205855 | 
 20200308210130 | 
 20200322214440 | 
 20200322214624 | 
 20200417175201 | 
 20200418230432 | 
 20200418230605 | 
 20200420215928 | 
 20200425182634 | 
 20200509103709 | 
 20200515172220 | 
 20200515195546 | 
 20200516123847 | 
 20200524221534 | 
 20200524224611 | 
 20200614113230 | 
 20200621214452 | 
 20200801183357 | 
 20200904101559 | 
 20200905151040 | 
 20200905232458 | 
 20200906184746 | 
 20201025195822 | 
 20201121181647 | 
 20201218152741 | 
 20201218220204 | 
 20201219145028 | 
 20210207192805 | 
 20210209204715 | 
 20210220222121 | 
 20210221111953 | 
 20210321185225 | 
 20210328191017 | 
 20210403145503 | 
 20210403220653 | 
 20210407170753 | 
 20210411113105 | 
 20210411161337 | 
 20210413131057 | 
 20210527105701 | 
 20210603174608 | 
 20210709191101 | 
 20210709211508 | 
 20210711173657 | 
 20210713213622 | 
 20210725153703 | 
 20210727204942 | 
 20210727211037 | 
 20210729142940 | 
 20210802081716 | 
 20210829194722 | 
 20211212151642 | 
 20211212210054 | 
 20220112211537 | 
 20220616145228 | 
 20220815200851 | 
 20221002120521 | 
 20221113170740 | 
 20221228112131 | 
 20230307171848 | 
 20230611170341 | 
 20230824132533 | 
 20230828125443 | 
 20230831155832 | 
 20230903143017 | 
 20230913202615 | 
 20231022144641 | 
 20231108231513 | 
 20240114224713 | 
 20230104152903 | 
 20231121191822 | 
 20240304153738 | 
 20240309111148 | 
 20240311173251 | 
 20240313230538 | 
 20240314214802 | 
 20240315093418 | 
 20240315104205 | 
 20240315110428 | 
 20240329170952 | 
 20240406125227 | 
 20240603172746 | 
 20240919130957 | 
(100 rows)

Listing the mirgations using the Vikunja CLI (/app/vikunja/vikunja migrate list) also shows newer migrations.

Output of "/app/vikunja/vikunja migrate list" 
2026/01/28 23:45:22 failed to create modcache index dir: mkdir /.cache: permission denied
time=2026-01-28T23:45:22.313Z level=INFO msg="Using config file: /app/vikunja/config.yml"
time=2026-01-28T23:45:22.317Z level=DEBUG msg="Redis initialized"
┌────────────────┬─────────────┐
│ ID             │ DESCRIPTION │
├────────────────┼─────────────┤
│ SCHEMA_INIT    │             │
│ 20190324205606 │             │
│ 20190328074430 │             │
│ 20190430111111 │             │
│ 20190511202210 │             │
│ 20190514192749 │             │
│ 20190524205441 │             │
│ 20190718200716 │             │
│ 20190818210133 │             │
│ 20190920185205 │             │
│ 20190922205826 │             │
│ 20191008194238 │             │
│ 20191010131430 │             │
│ 20191207204427 │             │
│ 20191207220736 │             │
│ 20200120201756 │             │
│ 20200219183248 │             │
│ 20200308205855 │             │
│ 20200308210130 │             │
│ 20200322214440 │             │
│ 20200322214624 │             │
│ 20200417175201 │             │
│ 20200418230432 │             │
│ 20200418230605 │             │
│ 20200420215928 │             │
│ 20200425182634 │             │
│ 20200509103709 │             │
│ 20200515172220 │             │
│ 20200515195546 │             │
│ 20200516123847 │             │
│ 20200524221534 │             │
│ 20200524224611 │             │
│ 20200614113230 │             │
│ 20200621214452 │             │
│ 20200801183357 │             │
│ 20200904101559 │             │
│ 20200905151040 │             │
│ 20200905232458 │             │
│ 20200906184746 │             │
│ 20201025195822 │             │
│ 20201121181647 │             │
│ 20201218152741 │             │
│ 20201218220204 │             │
│ 20201219145028 │             │
│ 20210207192805 │             │
│ 20210209204715 │             │
│ 20210220222121 │             │
│ 20210221111953 │             │
│ 20210321185225 │             │
│ 20210328191017 │             │
│ 20210403145503 │             │
│ 20210403220653 │             │
│ 20210407170753 │             │
│ 20210411113105 │             │
│ 20210411161337 │             │
│ 20210413131057 │             │
│ 20210527105701 │             │
│ 20210603174608 │             │
│ 20210709191101 │             │
│ 20210709211508 │             │
│ 20210711173657 │             │
│ 20210713213622 │             │
│ 20210725153703 │             │
│ 20210727204942 │             │
│ 20210727211037 │             │
│ 20210729142940 │             │
│ 20210802081716 │             │
│ 20210829194722 │             │
│ 20211212151642 │             │
│ 20211212210054 │             │
│ 20220112211537 │             │
│ 20220616145228 │             │
│ 20220815200851 │             │
│ 20221002120521 │             │
│ 20221113170740 │             │
│ 20221228112131 │             │
│ 20230104152903 │             │
│ 20230307171848 │             │
│ 20230611170341 │             │
│ 20230824132533 │             │
│ 20230828125443 │             │
│ 20230831155832 │             │
│ 20230903143017 │             │
│ 20230913202615 │             │
│ 20231022144641 │             │
│ 20231108231513 │             │
│ 20231121191822 │             │
│ 20240114224713 │             │
│ 20240304153738 │             │
│ 20240309111148 │             │
│ 20240311173251 │             │
│ 20240313230538 │             │
│ 20240314214802 │             │
│ 20240315093418 │             │
│ 20240315104205 │             │
│ 20240315110428 │             │
│ 20240329170952 │             │
│ 20240406125227 │             │
│ 20240603172746 │             │
│ 20240919130957 │             │
│ 20241028131622 │             │
│ 20241118123644 │             │
│ 20241119115012 │             │
│ 20250317174522 │             │
│ 20250323212553 │             │
│ 20250402173109 │             │
│ 20250624092830 │             │
│ 20250813093602 │             │
│ 20251001113831 │             │
│ 20251108154913 │             │
│ 20251118125156 │             │
└────────────────┴─────────────┘

Also, my bucket_configuration in project_views only has null and [] entries.

<!-- gh-comment-id:3814620649 --> @freeware-superman commented on GitHub (Jan 29, 2026): In all three cases (before migration and after migration before the first login attempt and after successful login) I have the same amount of entries in `users`. The table entry for the user that tried to login does not change. But it also does not update when changing any user setting in the web interface. --- In contrast to @SamBouwer's migration table, I'm missing all entries after `20240919130957`. Furthermore, I also only have one `SCHEMA_INIT` entry. <details> <summary>Output from "SELECT * FROM migration;" </summary> ``` postgres id | description ----------------+------------- SCHEMA_INIT | 20190324205606 | 20190328074430 | 20190430111111 | 20190511202210 | 20190514192749 | 20190524205441 | 20190718200716 | 20190818210133 | 20190920185205 | 20190922205826 | 20191008194238 | 20191010131430 | 20191207204427 | 20191207220736 | 20200120201756 | 20200219183248 | 20200308205855 | 20200308210130 | 20200322214440 | 20200322214624 | 20200417175201 | 20200418230432 | 20200418230605 | 20200420215928 | 20200425182634 | 20200509103709 | 20200515172220 | 20200515195546 | 20200516123847 | 20200524221534 | 20200524224611 | 20200614113230 | 20200621214452 | 20200801183357 | 20200904101559 | 20200905151040 | 20200905232458 | 20200906184746 | 20201025195822 | 20201121181647 | 20201218152741 | 20201218220204 | 20201219145028 | 20210207192805 | 20210209204715 | 20210220222121 | 20210221111953 | 20210321185225 | 20210328191017 | 20210403145503 | 20210403220653 | 20210407170753 | 20210411113105 | 20210411161337 | 20210413131057 | 20210527105701 | 20210603174608 | 20210709191101 | 20210709211508 | 20210711173657 | 20210713213622 | 20210725153703 | 20210727204942 | 20210727211037 | 20210729142940 | 20210802081716 | 20210829194722 | 20211212151642 | 20211212210054 | 20220112211537 | 20220616145228 | 20220815200851 | 20221002120521 | 20221113170740 | 20221228112131 | 20230307171848 | 20230611170341 | 20230824132533 | 20230828125443 | 20230831155832 | 20230903143017 | 20230913202615 | 20231022144641 | 20231108231513 | 20240114224713 | 20230104152903 | 20231121191822 | 20240304153738 | 20240309111148 | 20240311173251 | 20240313230538 | 20240314214802 | 20240315093418 | 20240315104205 | 20240315110428 | 20240329170952 | 20240406125227 | 20240603172746 | 20240919130957 | (100 rows) ``` </details> Listing the mirgations using the Vikunja CLI (`/app/vikunja/vikunja migrate list`) also shows newer migrations. <details> <summary> Output of "/app/vikunja/vikunja migrate list"</summary> ``` 2026/01/28 23:45:22 failed to create modcache index dir: mkdir /.cache: permission denied time=2026-01-28T23:45:22.313Z level=INFO msg="Using config file: /app/vikunja/config.yml" time=2026-01-28T23:45:22.317Z level=DEBUG msg="Redis initialized" ┌────────────────┬─────────────┐ │ ID │ DESCRIPTION │ ├────────────────┼─────────────┤ │ SCHEMA_INIT │ │ │ 20190324205606 │ │ │ 20190328074430 │ │ │ 20190430111111 │ │ │ 20190511202210 │ │ │ 20190514192749 │ │ │ 20190524205441 │ │ │ 20190718200716 │ │ │ 20190818210133 │ │ │ 20190920185205 │ │ │ 20190922205826 │ │ │ 20191008194238 │ │ │ 20191010131430 │ │ │ 20191207204427 │ │ │ 20191207220736 │ │ │ 20200120201756 │ │ │ 20200219183248 │ │ │ 20200308205855 │ │ │ 20200308210130 │ │ │ 20200322214440 │ │ │ 20200322214624 │ │ │ 20200417175201 │ │ │ 20200418230432 │ │ │ 20200418230605 │ │ │ 20200420215928 │ │ │ 20200425182634 │ │ │ 20200509103709 │ │ │ 20200515172220 │ │ │ 20200515195546 │ │ │ 20200516123847 │ │ │ 20200524221534 │ │ │ 20200524224611 │ │ │ 20200614113230 │ │ │ 20200621214452 │ │ │ 20200801183357 │ │ │ 20200904101559 │ │ │ 20200905151040 │ │ │ 20200905232458 │ │ │ 20200906184746 │ │ │ 20201025195822 │ │ │ 20201121181647 │ │ │ 20201218152741 │ │ │ 20201218220204 │ │ │ 20201219145028 │ │ │ 20210207192805 │ │ │ 20210209204715 │ │ │ 20210220222121 │ │ │ 20210221111953 │ │ │ 20210321185225 │ │ │ 20210328191017 │ │ │ 20210403145503 │ │ │ 20210403220653 │ │ │ 20210407170753 │ │ │ 20210411113105 │ │ │ 20210411161337 │ │ │ 20210413131057 │ │ │ 20210527105701 │ │ │ 20210603174608 │ │ │ 20210709191101 │ │ │ 20210709211508 │ │ │ 20210711173657 │ │ │ 20210713213622 │ │ │ 20210725153703 │ │ │ 20210727204942 │ │ │ 20210727211037 │ │ │ 20210729142940 │ │ │ 20210802081716 │ │ │ 20210829194722 │ │ │ 20211212151642 │ │ │ 20211212210054 │ │ │ 20220112211537 │ │ │ 20220616145228 │ │ │ 20220815200851 │ │ │ 20221002120521 │ │ │ 20221113170740 │ │ │ 20221228112131 │ │ │ 20230104152903 │ │ │ 20230307171848 │ │ │ 20230611170341 │ │ │ 20230824132533 │ │ │ 20230828125443 │ │ │ 20230831155832 │ │ │ 20230903143017 │ │ │ 20230913202615 │ │ │ 20231022144641 │ │ │ 20231108231513 │ │ │ 20231121191822 │ │ │ 20240114224713 │ │ │ 20240304153738 │ │ │ 20240309111148 │ │ │ 20240311173251 │ │ │ 20240313230538 │ │ │ 20240314214802 │ │ │ 20240315093418 │ │ │ 20240315104205 │ │ │ 20240315110428 │ │ │ 20240329170952 │ │ │ 20240406125227 │ │ │ 20240603172746 │ │ │ 20240919130957 │ │ │ 20241028131622 │ │ │ 20241118123644 │ │ │ 20241119115012 │ │ │ 20250317174522 │ │ │ 20250323212553 │ │ │ 20250402173109 │ │ │ 20250624092830 │ │ │ 20250813093602 │ │ │ 20251001113831 │ │ │ 20251108154913 │ │ │ 20251118125156 │ │ └────────────────┴─────────────┘ ``` </details> --- Also, my `bucket_configuration` in `project_views` only has `null` and `[]` entries.
GiteaMirror commented 2026-04-20 17:10:20 -05:00
Author
Owner
Copy Link

@freeware-superman commented on GitHub (Feb 1, 2026):

I just dug a little deeper and run all migrations using vikunja migrate rollback -n ### and vikunja migrate from the newest to the oldest.
After a rollback to migration 20241118123644 I get level=ERROR msg="Migration failed: migration 20250317174522 failed: pq: column \"oidc_id\" does not exist". With migration 20241028131622 and prior (e.g. 20241028131622) the error message changes to level=ERROR msg="Migration failed: migration 20241118123644 failed: pq: operator does not exist: json <> unknown".
Interestingly, these error messages do not happen when the docker container gets updated from v0.24.6 to v1.0.0.

Regardless of which migration is run, the migration table in Postgres does not get updated.

I also tried to access tasks directly, just like @SamBouwer, but I can't access any "old" task or project.

<!-- gh-comment-id:3831208128 --> @freeware-superman commented on GitHub (Feb 1, 2026): I just dug a little deeper and run all migrations using `vikunja migrate rollback -n ###` and `vikunja migrate` from the newest to the oldest. After a rollback to migration 20241118123644 I get `level=ERROR msg="Migration failed: migration 20250317174522 failed: pq: column \"oidc_id\" does not exist"`. With migration 20241028131622 and prior (e.g. 20241028131622) the error message changes to `level=ERROR msg="Migration failed: migration 20241118123644 failed: pq: operator does not exist: json <> unknown"`. Interestingly, these error messages do not happen when the docker container gets updated from v0.24.6 to v1.0.0. Regardless of which migration is run, the migration table in Postgres does not get updated. I also tried to access tasks directly, just like @SamBouwer, but I can't access any "old" task or project.
GiteaMirror commented 2026-04-20 17:10:21 -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:3951859384 --> @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)).
GiteaMirror commented 2026-04-20 17:10:22 -05:00
Author
Owner
Copy Link

@freeware-superman commented on GitHub (Mar 5, 2026):

I just tried updating from 0.24.6 to 2.1.0.

My Postgres DB still shows the same migrations as when testing 1.0.0 (up to '20240919130957'); with 'vikunja migrate list' the latest migration shows '20260225114726'.
'vikunja user list' shows no users while postgres lists them all.

Trying to sign in still leads to vikunja stating that there is no 'tl.permission' column.

<!-- gh-comment-id:4007516645 --> @freeware-superman commented on GitHub (Mar 5, 2026): I just tried updating from 0.24.6 to 2.1.0. My Postgres DB still shows the same migrations as when testing 1.0.0 (up to '20240919130957'); with 'vikunja migrate list' the latest migration shows '20260225114726'. 'vikunja user list' shows no users while postgres lists them all. Trying to sign in still leads to vikunja stating that there is no 'tl.permission' column.
GiteaMirror commented 2026-04-20 17:10:23 -05:00
Author
Owner
Copy Link

@kolaente commented on GitHub (Mar 17, 2026):

Is this your issue? https://github.com/go-vikunja/vikunja/issues/2397

<!-- gh-comment-id:4077010896 --> @kolaente commented on GitHub (Mar 17, 2026): Is this your issue? https://github.com/go-vikunja/vikunja/issues/2397
GiteaMirror commented 2026-04-20 17:10:25 -05:00
Author
Owner
Copy Link

@freeware-superman commented on GitHub (Apr 14, 2026):

Yes, this was part of it. After setting the schema correctly (VIKUNJA_DATABASE_SCHEMA: "vikunja"), I was able to upgrade my instance.
I updated from one version to the next and at one point got the same issue described here: https://github.com/go-vikunja/vikunja/issues/2397#issuecomment-4236364059. Executing ALTER TABLE users DROP CONSTRAINT idx_16580_primary; resolved this issue.
Later, there was an issue with migration "20260123000717" ("pq: column "project_id" of relation "webhooks" does not exist"). This can be resolved using ALTER TABLE webhooks ADD COLUMN project_id bigint;.

However, I'm not sure if this alters the DB to much or that there should have happened things to those columns and indexes before. Are these symptoms of a historically incorrect schema?
Is there a possibility to extract the data from the current instance and import it into a new/known good DB?

<!-- gh-comment-id:4247748636 --> @freeware-superman commented on GitHub (Apr 14, 2026): Yes, this was part of it. After setting the schema correctly (VIKUNJA_DATABASE_SCHEMA: "vikunja"), I was able to upgrade my instance. I updated from one version to the next and at one point got the same issue described here: https://github.com/go-vikunja/vikunja/issues/2397#issuecomment-4236364059. Executing `ALTER TABLE users DROP CONSTRAINT idx_16580_primary;` resolved this issue. Later, there was an issue with migration "20260123000717" ("pq: column \"project_id\" of relation \"webhooks\" does not exist"). This can be resolved using `ALTER TABLE webhooks ADD COLUMN project_id bigint;`. However, I'm not sure if this alters the DB to much or that there should have happened things to those columns and indexes before. Are these symptoms of a historically incorrect schema? Is there a possibility to extract the data from the current instance and import it into a new/known good DB?
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#6574
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?