Quick add magic for #list not working

Hello, I just installed Vikunja to try it out. Am using docker with a sqlite database. Noticed the following behavior after a fresh install (actually, after multiple fresh install attempts)

  1. Immediately after installation, there are no lists. Create two lists: Personal and Work. ← Works fine.
  2. At this point, there is no ‘Default list’ in the user settings. So adding a task with no #listname does not work. I think there is a message that a default list should be specified in settings. ← That is fine.
  3. Adding tasks with #Personal or #Work correctly adds them to the corresponding list. ← As expected.
  4. Now go to Settings and specify the Default list as Personal and hit Save.
  5. From this point on, regardless of which #list is specified when creating a task, it will go to the Personal list.
  6. Even if you enter a non-existent list when creating a task e.g. #no-such-list , the task will still go to the Personal list and it will not throw any errors (the Quick Add magic ‘What?’ help page says an error will be thrown if the list does not exist. This does not happen.)
  7. Now go to the settings and change the default list from ‘Personal’ to ‘Work’. Hit Save and go back to the Overview page.
  8. Now, any task added will go to the Work list, regardless of any #list used when creating it.
  9. Interestingly, if you try to remove the default list in the settings i.e. go to the settings page, delete the name of the default list previously specified so that the input field is blank, and hit Save, it does not work. You do get a green-background message saying that preferences are saved (or something like that). But if you then navigate away from the settings page (e.g. by going the Overview page) and then head back to Settings, you’ll not see a blank default list… it’ll be whatever value it had before you attempted to remove the default list.

Could someone verify this behavior? This makes Vikunja very bothersome to use, because I have multiple lists, but Quick Adding to a particular list with #listname simply does not work.

That sounds like a bug. Could you check if you can verify this on try?

[Edit: After typing the post below, with plenty of screenshots, and hitting ‘Reply’, it told me that new users are allowed to add only one screenshot and up to two links. So I’m adding only one, and hoping that my descriptions for the others will suffice.]

There seem to be multiple bugs with try that make it impossible to test if this behavior is occurring.

From the Overview page,

  1. If I try to add a task to an existing list e.g. “#hello This is a task”, it fails with message, “Error: Request failed with status code 404. The list does not exist.” even though the list clearly exists. See screenshot below

  1. If I then try to create a new list, named, testlist and then try to add a task to it from the overview page, it gives the same error (the list does not exist.) See screenshot below

[Screenshot from 2021-12-04 13-47-05|677x500]

  1. From the overview page, if I try to add a task without specifying any list, it still does not work, with the same error of the list not existing. Maybe there is some default list configured and it does not exist? See screenshot below

[Screenshot from 2021-12-04 13-47-40|677x500]

  1. Interestingly, instead of adding tasks from the overview page, if I click on one of the lists in the left panel, which opens up a page to add tasks to that list, then adding tasks works… again with some bugs. If a task is added “This is a task”, then it does get added to the list. But if a task is added in the page for hello list, but with a different #listname, then that task still gets added to the hello list as “#testlist This is a task” i.e. “This is a task” does not go in the testlist list. See screenshot below, where the task should have been added to the testlist, but has been added to the hello list.

[Screenshot from 2021-12-04 13-50-29|690x388]
[Screenshot from 2021-12-04 13-50-44|690x388]

So basically, I have been unable to test in try whether adding a task with #listA correctly adds it to listA :frowning:

Should be fixed with #1143 - fix: saving default list - frontend - Gitea

That is intended behavior. If you’re on the list and create a new task which would disappear right after creating it (because you specified another list that’s not the current one) that would be pretty confusing.

If you want to create a new task in list A while having list B open, I’d use the quick action bar and create a new task with the quick add magic from there.

Thank you. I’ll check in once #1143 is closed.

At the moment, I tried testing out the fix in #1143 through https://1143-fixtask-create-list--vikunja-frontend-preview.netlify.app/ (connected to https://try.vikunja.io as the API) but there seemed to be no change in the behaviors mentioned so far. Maybe this is not the right way to test the fix?

Sometimes the preview deploys don’t work correctly, but they should work in general. I was able to verify adding a task “new task +test” from the home page correctly adds it to the test list (on the review deploy). I had to enable the quick add magic in the settings though.

I guess the error message could be improved?

Apologies for bugging you about this, but any idea when #1143 will be closed? Also, once it is closed, will you be pushing a new image to Docker Hub (which is where I’m installing Vikunja from). I’m eager to start using Vikunja :slight_smile:

No worries!

It’s currently in review, shouldn’t take too long.

Yes, the CI will release a new image once the PR is merged.

@sagar The PR just got merged. The CI is quite busy right now but once this step passed there should be a new unstable release with the fix.

Thanks for reporting!

Hi, I think this issue still exists, or maybe its a variation of the error. I can’t seem to remove my preference for a default list, and thus the magic doesn’t add it to any list at all (whoops, thats not what happens. The magic adds it to the “removed” default list). No error is displayed, using v18.2 and v18.1 (front and backend)

There’s been a few improvements to this which are not yet released as a stable version. It looks like you are using the last stable release. Could you check this with the last unstable release or on try?

Aha, yeah you’re right, any idea how to move from stable to unstable while using docker? The image I’m using is served from vikunja/frontend and vikunkja/api.

Maybe its in the docs?

With docker, it should be enough to switch to the unstable tag on both containers.

1 Like