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 #897] Config file locations should follow service.rootpath set in a config #6311

New Issue
Open
opened 2026-04-20 16:53:31 -05:00 by GiteaMirror · 7 comments
GiteaMirror commented 2026-04-20 16:53:31 -05:00
Owner
Copy Link

Originally created by @eirnym on GitHub (Jun 7, 2025).
Original GitHub issue: https://github.com/go-vikunja/vikunja/issues/897

Description

Documentation states following:

In the service.rootpath location set in a config (remember you can set config arguments via environment variables)

I believe that app should follow documentation and read all config files recursively while updating in the opposite direction (e.g. First Read Last apply)

Vikunja Version

530fe4cef

Browser and version

No response

Can you reproduce the bug on the Vikunja demo site?

Yes

Screenshots

No response

Originally created by @eirnym on GitHub (Jun 7, 2025). Original GitHub issue: https://github.com/go-vikunja/vikunja/issues/897 ### Description Documentation states following: ``` In the service.rootpath location set in a config (remember you can set config arguments via environment variables) ``` I believe that app should follow documentation and read all config files recursively while updating in the opposite direction (e.g. First Read Last apply) ### Vikunja Version 530fe4cef ### Browser and version _No response_ ### Can you reproduce the bug on the Vikunja demo site? Yes ### Screenshots _No response_
GiteaMirror added the area/config label 2026-04-20 16:53:31 -05:00
GiteaMirror commented 2026-04-20 16:53:32 -05:00
Author
Owner
Copy Link

@kolaente commented on GitHub (Jun 13, 2025):

Can you explain why you think that should be the case?

<!-- gh-comment-id:2969200798 --> @kolaente commented on GitHub (Jun 13, 2025): Can you explain why you think that should be the case?
GiteaMirror commented 2026-04-20 16:53:34 -05:00
Author
Owner
Copy Link

@eirnym commented on GitHub (Jun 20, 2025):

Currently, it's a very confusing option, which can be specified as a config entry.

Option A:

Documentation states that config file will be read from the from that location and configuration option itself can be defined in a various places. including config file.

So I propose to make this configuration option consistent.

E.g. read location from config file, then apply the configuration file in that location and so on, making a potential chain. If chain is cycled, exit with error. Otherwise, apply the configuration in one or other direction, but consistent.

For example:

Llet's say a server has a global configuration in /etc/vikunja/config.yaml, which point to a site-specific /etc/vikunja/local/, in which config.yaml provides additional tweaks including an exact location to data files

Option B

State, that config.yaml won't be read from service.rootpath and should be supplied by:

  • An environment variable other than service.rootpath
  • specific set of locations (already established, but service.rootpath should be excluded because of it's not so clear how to apply it)
  • A config variable other than service.rootpath
  • Clearly state if one config file points to another location how configuration will be read.
  • Follow the previous statement
<!-- gh-comment-id:2989455924 --> @eirnym commented on GitHub (Jun 20, 2025): Currently, it's a very confusing option, which can be specified as a config entry. **Option A:** Documentation states that config file will be read from the from that location and configuration option itself can be defined in a various places. including config file. So I propose to make this configuration option consistent. E.g. read location from config file, then apply the configuration file in that location and so on, making a potential chain. If chain is cycled, exit with error. Otherwise, apply the configuration in one or other direction, but consistent. For example: Llet's say a server has a global configuration in `/etc/vikunja/config.yaml`, which point to a site-specific `/etc/vikunja/local/`, in which `config.yaml` provides additional tweaks including an exact location to data files **Option B** State, that `config.yaml` won't be read from `service.rootpath` and should be supplied by: * An environment variable other than `service.rootpath` * specific set of locations (already established, but `service.rootpath` should be excluded because of it's not so clear how to apply it) * A config variable other than `service.rootpath` * Clearly state if one config file points to another location how configuration will be read. * Follow the previous statement
GiteaMirror commented 2026-04-20 16:53:35 -05:00
Author
Owner
Copy Link

@kolaente commented on GitHub (Jun 24, 2025):

Currently, the root path is used, but only before the config file is read. This allows setting an env variable with a root path and then reading a config file from there. Further config files from a potential location set in that config file are not read after that.

I would accept a PR adding the behaviour you outlined, but it's unlikely that I'll spend time implementing it myself.

<!-- gh-comment-id:2999138412 --> @kolaente commented on GitHub (Jun 24, 2025): Currently, the root path is used, but only before the config file is read. This allows setting an env variable with a root path and then reading a config file from there. Further config files from a potential location set in that config file are not read after that. I would accept a PR adding the behaviour you outlined, but it's unlikely that I'll spend time implementing it myself.
GiteaMirror commented 2026-04-20 16:53:37 -05:00
Author
Owner
Copy Link

@eirnym commented on GitHub (Jun 24, 2025):

I understand. Could you please note this in documentation?

What would variant you prefer the most to implement? I personally prefer the second, but you may have other opinion

<!-- gh-comment-id:3000008288 --> @eirnym commented on GitHub (Jun 24, 2025): I understand. Could you please note this in documentation? What would variant you prefer the most to implement? I personally prefer the second, but you may have other opinion
GiteaMirror commented 2026-04-20 16:53:38 -05:00
Author
Owner
Copy Link

@kolaente commented on GitHub (Jun 24, 2025):

Added a note in b43728dd4a, should show up on the website soon.

Option B sounds simpler to implement, +1 from me.

<!-- gh-comment-id:3000472056 --> @kolaente commented on GitHub (Jun 24, 2025): Added a note in https://github.com/go-vikunja/website/commit/b43728dd4ab42e9976f78074ed7579b341d4e261, should show up [on the website](https://vikunja.io/docs/config-options/#config-file-locations) soon. Option B sounds simpler to implement, +1 from me.
GiteaMirror commented 2026-04-20 16:53:41 -05:00
Author
Owner
Copy Link

@dpschen commented on GitHub (Jun 26, 2025):

Unsure if we do this but it would be cool if there is a log entry that reports, which log file is currently in use.

<!-- gh-comment-id:3007737902 --> @dpschen commented on GitHub (Jun 26, 2025): Unsure if we do this but it would be cool if there is a log entry that reports, which log file is currently in use.
GiteaMirror commented 2026-04-20 16:53:42 -05:00
Author
Owner
Copy Link

@kolaente commented on GitHub (Jun 26, 2025):

A log entry is already happening.

<!-- gh-comment-id:3007781160 --> @kolaente commented on GitHub (Jun 26, 2025): A log entry is already happening.
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 area/config
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#6311
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?