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

Cannot Specify Non-Default List when Creating Item #40

New Issue
Closed
opened 2025-11-01 20:45:08 -05:00 by GiteaMirror · 9 comments
GiteaMirror commented 2025-11-01 20:45:08 -05:00
Owner
Copy Link

Originally created by @conor-f on GitHub (Mar 24, 2022).

This is a pretty annoying bug that has started happening to me recently. I can provide any additional information/test things for debugging if you let me know what to do! I run Vikunja with docker-compose behind Traefik on a home server. I ran docker pull vikunja/frontend and docker pull vikunja/api to get the newest latest. The frontend tells me:

Frontend Version: 0.18.2

API Version: v0.18.1

The issue I'm seeing is whenever I specify a list when creating an item, the item doesn't go to that list and just gets added to the default list regardless. e.g. If list A is my default list and B is another list, and I create the item Do this #B it will just add the item Do this to list A and nothing to list B. Other "Quick Add Magic" works fine (e.g. specifying the time) but this aspect does not.

Originally created by @conor-f on GitHub (Mar 24, 2022). This is a pretty annoying bug that has started happening to me recently. I can provide any additional information/test things for debugging if you let me know what to do! I run Vikunja with docker-compose behind Traefik on a home server. I ran `docker pull vikunja/frontend` and `docker pull vikunja/api` to get the newest `latest`. The frontend tells me: ``` Frontend Version: 0.18.2 API Version: v0.18.1 ``` The issue I'm seeing is whenever I specify a list when creating an item, the item doesn't go to that list and just gets added to the default list regardless. e.g. If list `A` is my default list and `B` is another list, and I create the item `Do this #B` it will just add the item `Do this` to list `A` and nothing to list `B`. Other "Quick Add Magic" works fine (e.g. specifying the time) but this aspect does not.
GiteaMirror added the bug label 2025-11-01 20:45:08 -05:00
GiteaMirror commented 2025-11-01 20:45:09 -05:00
Author
Owner
Copy Link

@kolaente commented on GitHub (Mar 24, 2022):

Can you reproduce this on try?

@kolaente commented on GitHub (Mar 24, 2022): Can you reproduce this on [try](https://try.vikunja.io)?
GiteaMirror commented 2025-11-01 20:45:10 -05:00
Author
Owner
Copy Link

@conor-f commented on GitHub (Mar 24, 2022):

I actually get different behaviour on try. It only adds to the default list but also doesn't remove the #otherListName which it does on my local instance. On a whim, I tried the auto add magic mode to Todoist and that seemed to work on try! Is this a newer version than on latest?

@conor-f commented on GitHub (Mar 24, 2022): I actually get different behaviour on try. It only adds to the default list but also doesn't remove the `#otherListName` which it does on my local instance. On a whim, I tried the auto add magic mode to Todoist and that seemed to work on try! Is this a newer version than on `latest`?
GiteaMirror commented 2025-11-01 20:45:10 -05:00
Author
Owner
Copy Link

@kolaente commented on GitHub (Mar 27, 2022):

Mhh sounds like this was fixed in the meantime but not backported to stable.

Does it make a difference if you set the quick add magic mode to Todoist or Vikunja?

Try runs the last unstable version, latest is the last stable release.

@kolaente commented on GitHub (Mar 27, 2022): Mhh sounds like this was fixed in the meantime but not backported to stable. Does it make a difference if you set the quick add magic mode to Todoist or Vikunja? Try runs the last unstable version, `latest` is the last stable release.
GiteaMirror commented 2025-11-01 20:45:10 -05:00
Author
Owner
Copy Link

@conor-f commented on GitHub (Mar 28, 2022):

Nope makes no difference to me what magic mode is being used, I'd just like the feature of putting items in different lists from the one input box!

Is it relatively safe to run try locally? From looking at the docker hub it's under the tag unstable?

@conor-f commented on GitHub (Mar 28, 2022): Nope makes no difference to me what magic mode is being used, I'd just like the feature of putting items in different lists from the one input box! Is it relatively safe to run `try` locally? From looking at the docker hub it's under the tag `unstable`?
GiteaMirror commented 2025-11-01 20:45:10 -05:00
Author
Owner
Copy Link

@kolaente commented on GitHub (Mar 28, 2022):

This really looks like a bug, I'll take a closer look.

Is it relatively safe to run try locally? From looking at the docker hub it's under the tag unstable?

Well it's bleeding edge so there's a few bugs here and there. From using it on my own instance I'd say it is definitely usable though.

@kolaente commented on GitHub (Mar 28, 2022): This really looks like a bug, I'll take a closer look. > Is it relatively safe to run try locally? From looking at the docker hub it's under the tag unstable? Well it's bleeding edge so there's a few bugs here and there. From using it on my own instance I'd say it is definitely usable though.
GiteaMirror commented 2025-11-01 20:45:10 -05:00
Author
Owner
Copy Link

@kolaente commented on GitHub (Apr 2, 2022):

Tried to reproduce this but it works without issues. Here's a video recording of it:

https://user-images.githubusercontent.com/13721712/161382732-feb44768-629a-4036-94bf-5e3fc675e11f.mp4

What exactly does not work when you use it? Can you provide clear steps to reproduce? Can you provide a recording of the bug?

@kolaente commented on GitHub (Apr 2, 2022): Tried to reproduce this but it works without issues. Here's a video recording of it: https://user-images.githubusercontent.com/13721712/161382732-feb44768-629a-4036-94bf-5e3fc675e11f.mp4 What exactly does not work when you use it? Can you provide clear steps to reproduce? Can you provide a recording of the bug?
GiteaMirror commented 2025-11-01 20:45:11 -05:00
Author
Owner
Copy Link

@conor-f commented on GitHub (Apr 4, 2022):

Sorry about this, quite a stupid mistake :(

It seems from your video that the correct syntax for specifying the list is to use + instead of #. From the help, I saw:

Assignees
To directly assign the task to a user, add their username prefixed with + to the task. You can use this multiple times.

List
To set a list for the task to appear in, enter its name prefixed with #. This will return an error if the list does not exist.

So maybe the fix is to just update the docs?

@conor-f commented on GitHub (Apr 4, 2022): Sorry about this, quite a stupid mistake :( It seems from your video that the correct syntax for specifying the list is to use `+` instead of `#`. From the help, I saw: > Assignees To directly assign the task to a user, add their username prefixed with + to the task. You can use this multiple times. > > List To set a list for the task to appear in, enter its name prefixed with #. This will return an error if the list does not exist. So maybe the fix is to just update the docs?
GiteaMirror commented 2025-11-01 20:45:11 -05:00
Author
Owner
Copy Link

@kolaente commented on GitHub (Apr 4, 2022):

The symbol used depends on the selected quick add magic mode. In the vikunja mode it is a + for lists, in the todoist mode it is a #. The docs change when the mode is changed in the settings.

I've checked again, the mode does not make a difference.

@kolaente commented on GitHub (Apr 4, 2022): The symbol used depends on the selected quick add magic mode. In the vikunja mode it is a + for lists, in the todoist mode it is a #. The docs change when the mode is changed in the settings. I've checked again, the mode does not make a difference.
GiteaMirror commented 2025-11-01 20:45:11 -05:00
Author
Owner
Copy Link

@conor-f commented on GitHub (Apr 4, 2022):

Sorry, I am no longer on the stable version of Vikunja so can't record a video to reproduce. I see the docs change when you change the magic mode on try.vikunja.io so I suppose this is all moot and any issue I was having will be fixed when the next release is cut to stable :)

@conor-f commented on GitHub (Apr 4, 2022): Sorry, I am no longer on the stable version of Vikunja so can't record a video to reproduce. I see the docs change when you change the magic mode on try.vikunja.io so I suppose this is all moot and any issue I was having will be fixed when the next release is cut to stable :)
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 bug
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#40
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?