Query/Search Function Not Working Properly?
Sorry if this is something that I've missed - I feel that must be the case. I know about the disappearance of the "q:" and that you can just type in the search box. However, when looking for an item with a keyword I am not getting the desired item returned as a possibility. In 7 Day View it's only returning possibilities from those 7 days. I could swear that when I used to enter a search the responses were pulled from every project across all dates. I've tried clicking on 'show all projects', and that doesn't pull it either. I've played with it purposely now and still I have the same results. Was there another change that I've missed? I have seen the "new" query page. Just in case you want to know, I am in Chrome using the Todoist extension as access.
Unfortunately, I can't reproduce it. I search for "va" and it shows all tasks and even when I use any other keyword, I see results that match tasks that are also long overdue or years into the future.
Please go to Chrome's Settings -> Advanced Settings -> Content Settings -> All cookies and site data and remove todoist.com from the list, reload your browser and let me know if the issue persists.
Also, make sure you're using the latest stable release of Chrome and not a beta or a dev version.
I first tried it on both Firefox & IE - same thing. But I am thinking that there may be an issue with the two things I tried to search. One was 'AT&T ... even tried just 'AT' in caps with no '&' sign - nothing. But I enter 'at' and the task I was checking on shows on the search. I also tried entering a monetary amount with the symbol, i.e., $90, and it wouldn't come up. Also tried without the $ sign and still nothing. But I tried another word - regular word - w/in the same task and it comes up. Is there a restriction regarding signifiers, caps and/or numbers?
Please clarify - do you experience the issue with the "viewall" query?
Regarding the other searches you've mentioned - I could reproduce this issue. It's a difficult problem if the search query includes any "special characters" that our parser can misunderstand. We're going to look into this and introduce an absolute search option in the future.
For now, in cases of AT&T and $90 please simply search for AT and 90 without using the q: syntax which will look for tasks that contain these letters numbers and will find these tasks.
I didn't go into View All specifically - I was checking first from my normal 7-Day view, and then to really check out the issue I searched right w/in the Project where the task was. I tried both with and without the"q:".
Just now I tried from both All & other views, including 7 Day. The plain 'AT' search works either way. The '90' search works only with the 'q:'. (And this task is not occurring w/in 7 Days, so it is pulling from all tasks even if I'm not in that view.) Neither work if I add the & or $, but the 'AT&T' search returns results - just none that have that in them as there is only one and it doesn't show.
P.S. I have recently discovered a few cool options/tools within TD that I hadn't delved into before. I continue to be amazed at how much I love "my" Todoist and all it can do to streamline one's life. And my beta iPad app has been awesome - a few small hiccups that are always corrected quickly. Overall, thanks again for offering a great product ... and more importantly at times, David, for your INCREDIBLE responsiveness and genuine concern in dealing with your sometimes-panicked masses. :)
We're glad to hear that :) As you might have noticed on social media, the iOS app is already under approval and there are more awesome changes coming across all platforms this year, we hope you'll love them :)
As for the issue with search - again, searches with such characters are always problematic. We currently have a "exact match" syntax that our parser understands and it's ^$. That is everything between ^ and $ should be an exact search query, for example: ^call Andy$ will never return tasks that just have "call" in their names.
It's not officially supported yet and it's certainly not an intuitive syntax, we're going to implement something easier (quotation marks?) and even ^$ has some issues with AT&T, but you're welcome to try it out :)
One more thing - you can use a dot as a wildcard to search for AT.T for example :)
Oh, that's a good one. Thanks for passing it along!
Unfortunately this doesn't just affect searches with special characters. Although the q: option is really great to know, as it seems to fix the issue, it doesn't really seem like a permanent solution to me.
Here's a screencast of this problem, searching simply for the word "vacation": http://screencast.com/t/bCMrtSGU6YW
I've had this happen for quite a few simple, single-word searches I've tried over the past week.
When I don't use q: it lists every single one of my tasks.
Thank you for your report. The word "vacation" starts with "va" and that's the shortcut we use for "view all". I have passed this to the developers and we'll try to make "va" an exception so it will not work if used within a word.
Another word to pass on would be "moniker", as it also appears to trigger mo/monday instead of searching.
We have now made "va" and exception so you can search for "vacation" without problems. As for other words that may start with a shortcut - we will address this issue in future updates, but for now, please use the standard q: syntax (used always for text-search in the past) in case a word triggers a different shortcut. Sorry for the inconvenience.
David, could you please clarify when you should/need to use the q: in your query as opposed to just typing your search word? I know the actual 'q:' prompt has been removed, but it seems like it still comes up in board discussions.
The q: syntax should be only used in case you look for a word that may collide with a common shortcut (tod, fri, thu etc.). We will consider improving the search even more to prevent such collisions, but for now, this is the best workaround to use when you won't see the expected search results and the word may include some of our shortcuts.
Got it! It's a back-up - THAT I can remember. Thanks, as always.
"As for other words that may start with a shortcut - we will address this issue in future updates, but for now, please use the standard q: syntax (used always for text-search in the past)"
You call it the "standard" syntax, but if I hadn't decided to search for my issue I wouldn't have known the q: option even existed. I'm also a brand new user, so how would I know that q: was always used for text-search in the past? I was actually pretty close to returning Todoist as my impression was that your search didn't work properly (which, let's be honest, it doesn't).
Considering a broken search could potentially cause someone to miss a task or project, you need a better way to alert users about the q: option and the fact that searching for a word with a reserved term is not going to give you the results you're looking for. Even a link near the search box that explains the situation would help.
"The q: syntax should be only used in case you look for a word that may collide with a common shortcut (tod, fri, thu etc.)"
And here you're making the assumption that every user is going to know every shortcut, which they aren't.
Although this might seem like a small issue to Todoist, to someone using your software to manage tasks that, if missed, would cause them to lose their job, it is definitely not a small issue.
And I'm not trying to sound like a jerk here, I absolutely love your software and don't know what I'd do without it now, I'm simply trying to give you the perspective of a new user.
I'm sorry for the misunderstanding, I meant "standard syntax" as in - this "type of syntax" (the standard of this syntax, not - this syntax is a standard). Of course this should not be a requirement and we will certainly improve the search in future updates.
These changes have been implemented quite recently and until now, the "q: " syntax was the only way to search for a word in a task and there was a "q: " link below the search box for quick use of this syntax. Now, we've enabled free search, but unfortunately, these issues occurred and we will surely address them.
Again, we're very sorry for the inconvenience, we indeed always aim at creating an intuitive software and this is a problem we're going to fix.