Currently I can “include” labels, search results, priority, etc in a filter.
But I can’t “exclude” anything as part of a filter. At least not from what I’ve seen so far. Here’s a request to add a way to exclude projects, search results, and other items from a filter. This way I can say “add all tasks labeled X but not those that come from project Y”
This will be possible with the new filter syntax.
On thanks. Is there a general estimate on when that may become available?
No eta, but if everything goes as planned it will be included in the next release.
You can now use query based filter logic since #2177 - feat(filters): query-based filter logic - vikunja - Gitea. Please check with the next unstable build if that fixes your problem.
I tested it for a moment. I went to create a new Saved Filter though, and when I tried to use project = <something>, I would click the name of the project in the dropdown and then it would just rever to project = undefined. I didn’t want to fiddle too much with it b/c I was operating on my day-to-day database instead of one for testing, so maybe I’ll spin up a separate one if more details are needed. I didn’t click the button to allow me to see the results, so maybe the ‘undefined’ was cosmetic (and it had selected the right project), or maybe it was actually busted.
But the direction it’s heading in is very pleasing and should be quite helpful!
(I hope that I’ll be able to create Kanbans as a side effect with these Saved Filters now that the filtering is different, is that going to be something to expect here or is that going to require something else entirely?)
Thank you for testing! Looks like the name was not properly resolved. This is now fixed in 22dcedcd7d. Please check with the next unstable build.
Not directly, but it is on the roadmap. The filter rework was a blocker for that, I’ll start working on that soon.
Not directly, but it is on the roadmap. The filter rework was a blocker for that, I’ll start working on that soon.
Great, that’s fine.
As for the queries, I’m running Version: v0.23.0+225-ca0de680ad and am currently using the latest ‘unstable’ which at the time of this writing was pushed an hour ago. Is there a way to know which unstable build pertains to a particular commit other than just installing?
Also can you help me understand how to use the Labels one? I have a couple of dummy projects with some tasks tagged with fun. I tried fun in labels but it keeps complaining:
Task filter value is invalid [Value: fun, Field: labels]
Am I running it right or no?
For me it works to simply type labels = IT, while the Frontend will already starts to offer autocompletion once you enter the equality sign. Although it looks like the labels in [IT] syntax is not supported.
Ah yes I see. I would have expected the use of the ‘in’ operator
That was also my first attempt. Not sure if its supposed to be supported or not
Not really, you’ll have to install it to find out which version it uses.
in filters should work in principle, but I think the label title → id resolvement does not work. I’ll take a look.
The in operator now works as you’d expect: dbfe162cd2 and 0529f30e77. Please check again with the next unstable build.
Thanks for the updates! I can confirm that both the:
labels = INSERT_LABEL
and the
labels in [INSERT_LABELS]
seem to be working appropriately on the most recent build, however it does not seem to allow me to use any kind of negating logic with labels, such as:
labels != INSERT_LABEL
And from taking a quick peek at the source, my current understanding is that there is no “not” negating operator implemented either, as it might look in the below example?
labels not in [INSERT_LABELS]
Not sure if using negating logic is just not an intended use case, or if this is a bug/error. In either case, many thanks for the help and all your amazing work!
This worked for me, can you (still) reproduce this on try in ~45min? There have been a few fixes in the filter query logic, maybe that has fixed your problem as well.
That’s correct. There is only a != operator. Might get added in the future.
Thanks for the quick response! So I got into the try.vikunja.io version and tested out my use case - and still got the same output as before, however now I think I have identified why:
If the task has more than one label applied, the notation of != is taking it as a literal inequivalence, or only filtering those tasks where ONLY that is matched. So if I have label1 and label2 on a task, this means that:
labels != label1
will not filter out my task label1 label2 because it is not an exact match for the filter. I was using it from the perspective that labels != label1 meant “return all tasks that do not have label1 applied to it.”
I’m not sure if this was a crazy thing to assume it functioned that way (no offense taken if you think so!) when I was trying to construct my filter, but if you think it isn’t - then perhaps it could be useful to other users to add a line in the helpful “How does this work?” documentation to maybe clarify that != is straightforwardly only going to return a strict inequivalence, rather than be able to act as a drop in for something like a not operator.
Anyways, after realizing that it was looking for exact matches only, I tried to construct a few filters to figure out how to filter out the multi-label tasks. Among others, I tried the following:
labels != (label1 && label2)
labels != ['label1', 'label2']
Perhaps my basic query logic is off, but I think that without the not operator, or perhaps modifying the label filter to not require exact matches, or some kind of similar mechanism - this means that it is currently impossible to filter out any tasks that are multi-labeled tasks via a label filter?
Thanks again, and appreciate you looking into it!