When I am on a list, do a search, and then hit esc twice, I expect the expanded/collapsed state of all the tasks in the list to be exactly as it was before I started doing the search. But for my lists, this isnāt the case: after pressing esc twice, I end up with lots of expanded tasks, which were not expanded before doing the search.
My workaround is then do a ctrl-shift-left (collapse all), but the main problem with this is that I loose the expanded state of nested tasks, which Iād like to keep, and is important to me. Somehow, this currently is my main problem with Checkvist, and without trying to sound too dramatic :), it is somewhat of a showstopper.
I havenāt been able to reproduce this on simpler lists that I create from scratch, which I tried to do to provide a better description of the issue here. Instead, I only seem to have this problem with my ārealā lists that contain from 600 to 1200 tasks.
Is this a behavior that the developers on Checkvist are aware of? If so, do you consider this a bug and are looking into fixing it? If not, how can help you reproduce it?
After seeing the following comment by @maxkir, I am worried that the above behavior I had thought to be āclearly a bugā, might not be one:
@Bob_Butler You can collapse all notes with sn keyboard shortcut after the the search. You can also collapse all items to top level with Ctrl+Shift+Left keyboard shortcut.
The thing is that doing a Ctrl+Shift+Left after a search wonāt leave your list in the same state as it was before the search. In other words: whatever you do, youāre having a side effect on your list by simply doing a search, which in principle doesnāt sound like a good idea to me, and is particularly problematic when you associate meaning to branches being opened or collapsed, as you loose that information just by searching through the data. This is a sort of Checkvist observer effect ;).
I a now really curious to learn if the current behavior is seen by the team something done by design and they want to keep going forward, or something theyād like to change in a not-too-distant future.
Thanks for pointing out to the problem. This is definitely a bug, and it is not intended that the list changes its collapse/expand state after filtering/unfiltering. Weāll try to fix it in one of the next updates, but unfortunately, I cannot give estimates, as this problem is not a trivial one.
Weāre going on vacation soon, maybe will have time to resolve it there
I am glad to read this. As usual, thank you for the quick response (your responsiveness on this Discourse is very much appreciated!). Iām looking forward for this to being fixed, and enjoy your vacation (which is more important than a fix)!
I should also say that I have the same problem when navigating to a task from the global search or with a link that I had bookmarked. Doing so expands all ancestors, and this āexpanded stateā is persisted.
Next time I open the list, all those nodes will show as expanded. As with search, merely navigating to a task (link with #task_123) is having an unavoidable side effect on the expanded/collapsed state of the tasks in my list.
Would you consider this to be the same problem as what is happening with search? Or a different problem? Or maybe not a problem at all, but a behavior that youād like to keep?
So far Iām not sure that the latter case is a bug, at least we never considered such behaviour as a problematic one. But I see your point, it makes sense, just Iām not sure what would be the expected behaviour for other our customers.
When Iāll be fixing the issue with filtering, Iāll try to check this case as well, thanks!
Awesome! The first change greatly improves search, and the second one will save me from having to close all the ancestors of a task I just navigated to, say from the Due page.
Iāve tested this a bit, and it just seems to work great. Iāll keep using the beta site, and will make sure to let you know if I notice any quirk. Again, thank you for the great support, and for how quickly you guys are addressing issues reported here!
