[patch] Allow to ignore tag selection with specific syntax
This patch allow to ignore a tag selection to be able to provider a "all" choice for end-users.
A complete description of the case may be found there: http://lists.typo3.org/pipermail/typo3-english/2010-December/072385.html
PS: The documentation is not updated by this patch.
#2 Updated by Francois Suter almost 7 years ago
- Status changed from New to Needs Feedback
- Assignee set to Francois Suter
I find relations between this issue and #11199. First of all - at first glance - I would say your patch will work only if the patch from #11199 is already applied (otherwise, no tags will be selected). Furthermore if all expressions were resolved to \all, we could benefit from the proposal I made in #11199 to return \all in the idList instead of all UIDs.
What do you think?
I also thought that we need to take the logical operator into account. If it's "OR" and at least one expression evaluates to \all, then all UIDs must be taken. On the contrary, if it's "AND" only the "non-\all" expressions must be considered (of course, if there's only one expression and it evaluates to \all, then we select all).
#3 Updated by Adrien Crivelli almost 7 years ago
I agree with you on all points:
- The patch #11199 was (and still is) applied when I tested this patch.
- Optimisation in the case of everyhing resolved to \all could be made.
- And OR/AND operators is an obvious point I missed (my case use OR).
I am wondering if "\all" is the right term. Would "\ignore" be more meaningful ? As you stated in the case of AND we need to consider the "non-\all", it may be more straightforward for the user to think "non-\ignored" instead... not sure about that though I need to clear my mind before arguing any further.
#4 Updated by Francois Suter almost 7 years ago
I'm suggesting \all because it's already used in Data Filter and I think it's meaning is quite clear. Of course, when it's reversed (i.e. "non-\all"), it gets a bit more complex, but I'm not sure \ignore helps in that case. At some point - when one is designing conditions - one needs to know a bit of logic ;-)
#9 Updated by Francois Suter over 5 years ago
- Status changed from Needs Feedback to Accepted
You're right, the feedback status is not right anymore. I had just updated the issue because I need to release a version 1.2.0 before I actually tackle this bug. Honestly I'm not sure when I'll do that. Tagpackprovider is not the component we use most, especially since tagpack itself is not developed anymore.
I'll try to take care of this at some point. Sorry for the delay.
(same goes for the other issue).
#12 Updated by Adrien Crivelli about 1 year ago
@François, could you also please close this second ticket ?
I can't do it myself and we merged this patch a long time ago in our fork in https://github.com/Ecodev/tagpackprovider/commit/02f3cb27c55c96c91761a3dc0b0cca66d7f93d23