Adding sql ORing capability with filters
| Project: | Views |
| Version: | 6.x-3.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | merlinofchaos |
| Status: | active |
| Issue tags: | views 3.x roadmap |
Unless I'm mistaken, I don't think its possible to OR filters together instead of ANDing them when setting up a view.
Let me explain where I'm coming from with this.
With my project, I have a content type "Project" with 3 user reference fields - Team Manager, Designers, and Programmers. I would like to create a view of "My Projects" where my user is referenced in either one of the three user reference fields.
From a UI perspective, I had in mind an addition to the filters table called "Group" which would either be a textfield or a dropdown of numbers (say 0-20). When you setup your filters, you put the fields you want ORed together into the same group. All the groups will be ANDed together while all fields inside a group are ORed against each other.
Using my example, I would have 4 filters:
- Node Type = Project, no group
- Team Manager = Current User, group 1
- Designer = Current User, group 1
- Programmer = Current User, group 1
The resulting query having something like: node.type = "content_project" AND (content_field_manager = 1 OR content_field_designer = 1 OR content_field_programmer = 1)
Does that sound reasonable, and if so what about the UI to handle it? I get the feeling that it may be a big deal to get this working properly as there are a lot of things that may need to change (database structure?) and some that may break (exposed filters?).
Thoughts? Comments? Worth implementing?

#1
I have a plan for including a primitive OR in Views 2; but it's unlikely that it will make it into the current version of Views, and Views is a little ways out.
I realize this is a difficult limitation, but right now it's what you got. Your best bet for a work around would be to use the Views API and expose a filter that can do what you need. It's a bit complex but it is possible.
#2
This plan got punted to Views 2.1 -- asisigning ot myself so I can find this for marking duplicates.
#3
I am very interested in this feature, if you need help of any kind I'll be glad to jump in.
#4
I am also very interested in this feature ...
My site deals with product development projects in different development stages. I'd like to create a table view with columns representing each stage (4 or 5 stages), and simply populate the table with the node title as a link to the full record (sample image attached without columns filtered by stage). Each column would need to be filtered to the respective stage for that column. I would also add ANDed filters for selecting the displayed subset by business unit, for example, or perhaps even a subcategory within a business unit. The desired feature is to have projects "move" from stage to stage in this view by simply updating the stage field as the project progresses from stage to stage.
Will this be possible with Views 2.X?
#5
Is the only way of doing this at present still $query->add_where in a filter handler, per #56444: ability to logically OR filter clauses?
I was hoping there might be a way of "adding" together the results of 2 separate Views ... actually I thought maybe that was what attachment displays did, until the penny dropped!
#6
This will be such a killer feature ;)
After IRC with merlinofchaos, i wanted to note two things:
#7
Thanks scottrigby.
FWIW, adding a link to views_or, which looks very promising: http://drupal.org/project/views_or.
#8
Is this coming soon? Should we use views or at this stage?
#9
+1
#10
+1
#11
+1
#12
+1
#13
+1 here. Using views_or which is fantastic, just want to keep updated for when the migration to Views2 takes place.
#14
subscribing
#15
Subscribed.
#16
guess I'm going to try the views or,...
#17
Subscribed.
I really, really need this for my web site.
The views_or module is in a dev rev, so I am not using it, although in principle it would meet my needs.
But I am extremely grateful for Views itself already - I think it is awesome and already has allowed me to do so much.
So I respect merlinofchaos' time, and I will wait patiently.
#18
adding a tag und pumping to 3.x
#19
subscribe
#20
View_or just broke for me with the new dev version. I'm excited to see this making it's way into views proper.
#21
track
#22
+1 using views or currently but looking for when it will be included into views
#23
+1
#24
+1 Subscribe
#25
+1 subscribing
#26
Subscribe, +1
#27
Anything new about it?
#28
Subscribing
#29
Subscribe.
#30
For Shizzle
#31
subscribe
#32
+1
#33
subscribing.
#34
subscribing....
#35
subscribe
#36
subscribe
#37
subscribe
#38
I have created an initial UI to see if this is what we are looking for.
Views 2, and 3 already provide a mechanism to group filters using OR. We only need a user interface to configure this settings.
Since views 3 introduces Group By, these filters cannot be grouped into the same groups that non aggregated filters.
For this reason, this UI provide an special group to put all "COUNT. SUM, MAX, etc " filters.
A similar UI can be defined to #141342: Allow disjunctive conjunction (OR) of arguments
I used firebug to produce this UI, sorry a patch for this UI is a little complex and we first need to know what kind of UI are we looking for.
#39
Hi dagmar
It's so great you're working on this! I've been trying to learn Drupal insides better to look at just this problem... still a ways off tho!
I think what you've done looks excellent - just the kind of thing we need. First of all can I check I understand correctly. The example you gave evaluates as
( (NID >= 3) OR (Type == Page) OR (NID != 26) OR (Published) ) OR //group 0( (NID >= 3) AND (Type == Page) ) OR //group 1
( (NID >= 3) AND (Type == Story) AND (NID != 500) AND (Published) ) OR //group 3
( (Count >= 3) ) //aggregator group
Is that right?
I was wondering... is it necessary to have all those choices of AND/OR? I find logic a sticky area, but it seems to me you could get the same effective results as the screenshot with this.
( a AND b AND c ... ) OR ( d AND e AND f ... ) OR ...IE the groups are always ORed and within groups the logic is always AND. The only problem I can see with that for normal (non-aggregated groups) is for XOR. A simple test like
( a AND b ) XOR ( c AND d)can't be done AFAICT with this system. However it would still make the filters much more powerful IMHO, even without that capability.Regarding aggregated filters, I don't know Views 3, and I'm not sure I fully understand what you said about them. From what I can grok, I think they might need their own set of groups (rather than a single group), in case I want to do something like...
( ( count > 3) AND ( max > 100 ) ) OR( ( sum > 300 ) )
Does that make sense?
Some other possible ideas:
cond1 = a AND bcond2 = c AND d
( cond1 AND !cond2 ) OR
( cond2 AND !cond1 )
( a AND b AND !( c AND d) ) OR( c AND d AND !( a AND b) )
I know you're really asking about UI, and I'm not sure the best way to do this without cluttering the interface and confusing users. Maybe something similar to the hierarchical drag and drop for organising eg. menu items?
Btw, I'm using the XOR in these two examples arbitrarily - the methods can be used to achieve other kinds of logic.
I hope all of this is meaningful! Thanks for the work you've done so far, this is a real important piece of functionality IMHO.
#40
subscribe
#41
Yes, it is correct.
Mmm I'm afraid that this is not correct. There is some kind of filters that needs this structure (a OR b) and (c OR d) and they cannot be easily converted into an (w AND x) OR (y AND z) form.
I think this is possible too, I only have to include another button to create a aggregation group. I search into views 3 api and this is currently possible by code, so, it can be implemented using the UI.
Mmm this is not currently possible. The secret of how groups are joined resides into function condition_sql() in views_plugin_query_default.inc, as you can see here views uses implode to join all these groups using "$this->group_operator" so, create subgroups it isn't currently possible.
Anyway, with the actual api of view there are a lot of possiblilities, I think that we first should provide the UI for this api, and next see if we can implement other features.
#42
I'm with you, thanks for the reply. Then IMHO it seems you've got a really nice UI if you can handle those aggregated filters like you mentioned.
#43
This is the new UI with the discussed changes.
#44
subscribe
#45
I don't believe that aggregated filters will need their own groups. At least, I don't understand why they should. From the perspective of this level, they're just filters with extra goo on them, aren't they?
Otherwise, I like this UI. My initial thoughts were to use tablesort's hierarchy but I think just using different tables for the OR groups is better.