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

[GH-ISSUE #91] User Language unset while upgrading from 0.20.X to 0.21.0 #5957

New Issue
Closed
opened 2026-04-20 16:24:52 -05:00 by GiteaMirror · 2 comments
GiteaMirror commented 2026-04-20 16:24:52 -05:00
Owner
Copy Link

Originally created by @gordonlau on GitHub (Oct 28, 2023).
Original GitHub issue: https://github.com/go-vikunja/vikunja/issues/91

Description

We are self hosting the vikunja using docker compose with the following configuration.

version: '3'

services:
  postgres:
    image: postgres:13
    env_file:
      - ./envfile
    environment:
      POSTGRES_USER: vikunja
    volumes:
      - ./db:/var/lib/postgresql/data
    restart: unless-stopped
  api:
    image: vikunja/api:0.21.0
    env_file:
      - ./envfile
    ports:
      - 8080:8080
    volumes:
      - ./files:/app/vikunja/files
      - ./config:/etc/vikunja
    depends_on:
      - postgres
    restart: unless-stopped
  frontend:
    image: vikunja/frontend:0.21.0
    ports:
      - 3000:80
    env_file:
      - ./envfile
    restart: unless-stopped

While we are updating Vikunja to the latest available version (0.21.0), some users managed to login successfully. But some users fail to do so. Upon carefully examining and reading this link, we discover that it is due to a column language in the table users being <unset> for a bunch of users.

Here are the difference between the users that can login and those who can't.

The can-login users.

       name        | language 
-------------------+----------
 Person 1       | en
Person 2          | en
Person 3          | en
Person 4        | en
... rest of the rows
(10 rows)

The failed to login users,

vikunja=# select name, language from users where not  language  = 'en';
          name          | language 
------------------------+----------
Person 1          | <unset>
Person 2              | <unset>
Person 3              | <unset>
Person 4  | <unset>
Person 5              | <unset>
... rest of the rows

Basically I fix the issue by setting everybody's language to en.

update users set language = 'en' where not language = 'en';

Then everything works. I think it might be due to not expecting user to have their language in an <unset> state.

Vikunja Frontend Version

0.21.0

Vikunja API Version

0.21.0

Browser and version

Chromium Version 118.0.5993.117

Can you reproduce the bug on the Vikunja demo site?

No

Screenshots

No response

Originally created by @gordonlau on GitHub (Oct 28, 2023). Original GitHub issue: https://github.com/go-vikunja/vikunja/issues/91 ### Description We are self hosting the vikunja using docker compose with the following configuration. ```yaml version: '3' services: postgres: image: postgres:13 env_file: - ./envfile environment: POSTGRES_USER: vikunja volumes: - ./db:/var/lib/postgresql/data restart: unless-stopped api: image: vikunja/api:0.21.0 env_file: - ./envfile ports: - 8080:8080 volumes: - ./files:/app/vikunja/files - ./config:/etc/vikunja depends_on: - postgres restart: unless-stopped frontend: image: vikunja/frontend:0.21.0 ports: - 3000:80 env_file: - ./envfile restart: unless-stopped ``` While we are updating Vikunja to the latest available version (0.21.0), some users managed to login successfully. But some users fail to do so. Upon carefully examining and reading [this link](https://community.vikunja.io/t/error-refreshing-user-info-on-new-install/1470/6), we discover that it is due to a column `language` in the table `users` being `<unset>` for a bunch of users. Here are the difference between the users that can login and those who can't. The can-login users. ```sql name | language -------------------+---------- Person 1 | en Person 2 | en Person 3 | en Person 4 | en ... rest of the rows (10 rows) ``` The failed to login users, ``` vikunja=# select name, language from users where not language = 'en'; name | language ------------------------+---------- Person 1 | <unset> Person 2 | <unset> Person 3 | <unset> Person 4 | <unset> Person 5 | <unset> ... rest of the rows ``` Basically I fix the issue by setting everybody's language to `en`. ```sql update users set language = 'en' where not language = 'en'; ``` Then everything works. I think it might be due to not expecting user to have their language in an `<unset>` state. ### Vikunja Frontend Version 0.21.0 ### Vikunja API Version 0.21.0 ### Browser and version Chromium Version 118.0.5993.117 ### Can you reproduce the bug on the Vikunja demo site? No ### Screenshots _No response_
GiteaMirror commented 2026-04-20 16:24:53 -05:00
Author
Owner
Copy Link

@gordonlau commented on GitHub (Oct 28, 2023):

Just to re-iterate, I am aware that setting the language in config to en fixes this issue.
But I think the frontend should probably take this case( the <unset> case) into account or the language should have a reasonable default like en.

  # The language of the user interface. Must be an ISO 639-1 language code. Will default to the browser language the user uses when signing up.
  language: <unset>
<!-- gh-comment-id:1783857608 --> @gordonlau commented on GitHub (Oct 28, 2023): Just to re-iterate, I am aware that setting the language in config to `en` fixes this issue. But I think the frontend should probably take this case( the `<unset>` case) into account or the language should have a reasonable default like `en`. ```yaml # The language of the user interface. Must be an ISO 639-1 language code. Will default to the browser language the user uses when signing up. language: <unset> ```
GiteaMirror commented 2026-04-20 16:24:54 -05:00
Author
Owner
Copy Link

@kolaente commented on GitHub (Oct 29, 2023):

The frontend will check the browser's language and set it if there's no language saved for that user. Having <unset> as a value in the config file will override that logic as there is a value set (<unset> as a literal value). You should only use the key if you intend to set a default value and in that case, are responsible to set a valud value. <unset> is an invalid value.

<!-- gh-comment-id:1784197216 --> @kolaente commented on GitHub (Oct 29, 2023): The frontend will check the browser's language and set it if there's no language saved for that user. Having `<unset>` as a value in the config file will override that logic as there is a value set (`<unset>` as a literal value). You should only use the key if you intend to set a default value and in that case, are responsible to set a valud value. `<unset>` is an invalid value.
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#5957
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?