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

[GH-ISSUE #495] Use vue router navigation guards to prevent accessing caldav and TOTP settings when they are disabled #6188

New Issue
Closed
opened 2026-04-20 16:47:26 -05:00 by GiteaMirror · 1 comment
GiteaMirror commented 2026-04-20 16:47:26 -05:00
Owner
Copy Link

Originally created by @vikunja-bot on GitHub (Apr 1, 2025).
Original GitHub issue: https://github.com/go-vikunja/vikunja/issues/495

Original issue by @kolaente on 2021-10-26T20:18:02.000Z

Follow-Up for #889 and related to #899.

It should not be possible to access the caldav or totp setting routes when they are disabled server side. The problem here is these depend on a call to /api/v1/info which populates the server settings in local state. The check needs to happen after that.

Original issue on Gitea

dpschen commented on 2021-11-26T13:23:21.000Z:

This is possible with navigation guards

Originally created by @vikunja-bot on GitHub (Apr 1, 2025). Original GitHub issue: https://github.com/go-vikunja/vikunja/issues/495 _Original issue by @kolaente on 2021-10-26T20:18:02.000Z_ Follow-Up for #889 and related to #899. It should not be possible to access the caldav or totp setting routes when they are disabled server side. The problem here is these depend on a call to `/api/v1/info` which populates the server settings in local state. The check needs to happen after that. [Original issue on Gitea](https://kolaente.dev/vikunja/vikunja/issues/1851) --- _**dpschen** commented on 2021-11-26T13:23:21.000Z_: This is possible with navigation guards
GiteaMirror added the area/frontendarea/caldavarea/internal-codearea/auth labels 2026-04-20 16:47:27 -05:00
GiteaMirror commented 2026-04-20 16:47:30 -05:00
Author
Owner
Copy Link

@vikunja-bot-app[bot] commented on GitHub (Apr 15, 2026):

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

<!-- gh-comment-id:4251205189 --> @vikunja-bot-app[bot] commented on GitHub (Apr 15, 2026): This issue has been fixed in #2629, 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 area/auth area/caldav area/frontend area/internal-code
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#6188
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?