Allow to limit which exposed operators apply

This is definitive cool. Here is a review from the train

Even if you have just selected "is less / is equal to" you get two value fields. So you get
* the value field
* the max/min field.

+      $limit = array_filter($this->options['expose']['limit_operators']);
+      if (count($limit)) {
+        foreach ($options as $key => $value) {

Could we check for "unlock operator" here too? It would be easier for the user if he clicked
around and realized that this was not he wanted. Now he has the enable every operator first/disable every operator. It would be cool if the user could remove the checkbox
from "unlock operator" and all works as before.

+          '#prefix' => '<div id="edit-options-expose-limit-operators-wrapper"><div id = "edit-options-expose-limit-operators">',
+          '#suffix' => '</div></div>',

Where do we need this? Is this for the js? Or the not needed css?

Ooh, I like this :)

Both patches apply cleanly.
Tested the 3.x patch, works as it should.

Noticed that it uses "else if" instead of "elseif" in code, but since views itself is inconsistent with that (6.x uses "else if" mostly, while 7.x uses "elseif" mostly), not going to complain here.

Not comfortable setting this RTBC myself, so sending out a nudge to dereine.

There are many more filter handlers which implements value_form. We might have to fix quite some of them.

Other examples views_handler_filter_equality, views_handler_filter_term_node_tid

Once we have them i guess this is rtbc.

+1. Like this.

Going to send this back for one modification: Let's gate this by a checkbox.

I.e, "[ ] Limit list of available operators" which then opens up the list of operators to be selected down.

Looks ok. Do we need to fix other handlers per #8?

What about contrib modules?

For example date module would not support this feature out of the box

Converted all other instances of operator_form

I guess other modules that are doing something different for allowable operators would have to catch up. I'm okay with that.

Committed to 6.x-3.x

Subbing

Here is an initial port of the patch.

It would great if someone could provide some testing.

Just in general this procudes a call to undefined function error, so update patch.

@dagmar
It would be great if you could have a look at the patch and try to get it ported.

Update status

Did this feature get into the most recent release of Views for D7? I believe it was the one from June 17th, just over a week ago. Also, I'm very new, could someone point me in the direction of how to apply a patch? (link or something, all I keep finding on Drupal is how to submit a patch, not use it, and again, I'm very new to site design, sorry for the stupid question)

This is a real problem for me and also if you choose to expose the filter for the body field in article (and I think for any rich text field) and you expose the operator then try selecting empty/or not empty, it does not work and disappears from the display (JS bug in D7 and overlay )

Please if any has found a proper solution or if you can instruct us to apply the patch without cvs would be great

Thank You,

@AtomicTangerine
Sometimes i'm wondering whether people can read and take logical inferences based on it...
If there would be this patch applied this issue would be marked as fixed. If this is just a try to push the issue, good luck, it works always the other way round.

@awm086
As wrote above, this patch isn't ported yet and needs help. A missing feature shouldn't be a "real problem".

Okay wasted another 5mins just to think about this comment. Great!

I'm trying to figure out if this has been applied to 6.x code?
#13 seems to indicate that it has been applied against 6.x.3.x, but I would expect to find a seperate issue for 6.x, which I could not find.

Can someone clearly state if this is applied to 6.x, and to which version. If it has not been, is there a patch I can apply?

It is applied to 6.x-3.x-dev see http://drupal.org/node/873872#comment-4050370

Thanks, I appreciate the help.

I have updated views to the 6.x-3.dev code, and have also tried the 6.x-3.alpha code with the patch supplied in #13 above. though it seems to work, I now get the follwowing errors:

warning: invalid argument supplied in foreach() in c:\inetpub\wwwroot\drupal-6.20\sites\all\modules\views\plugins\veiws_plugin_query_defualt.inc on line 879
This one is easy to resolve, by putting an if statement around foreach block to test if $fields_array is empty.

but I also get:
user warning: you have an error in your SQL syntax; check manual that corresponds to your mysql server version for the right syntax to use near 'FROM node node LIMIT 0,1' at line 2 query: SELECT DISTINCT FROM node node L:IMIT 0,1' in in c:\inetpub\wwwroot\drupal-6.20\sites\all\modules\views\plugins\veiws_plugin_query_defualt.inc on line 1093

This is in the execute() function, line $result=db_query_range($query, $args, $offset, $limit);

Any help here would be appreciated

@geoffv
Can you please open a new issue for this bug and try to describe it so we can reproduce it. Thanks
Putting multiple issues in one issue is really hard to manage.

new issue raised http://drupal.org/node/1235372

Triggering the testbot.

Rerolled.

Patch works, but when I only select the (NULL / NOT NULL) operators, I get no results when clicking on the view. When I submit the filter (without changing anything), I get my results then.

#32: 873872-32.limit_operators.patch queued for re-testing.

32: 873872-32.limit_operators.patch queued for re-testing.

Re-rolled for fuzz.

Working good here.

This is working except for one small point; If you are E.g. using a filter that has the default operator set ('=') and this is not in 'limit_operators' you will get an invalid form value. So we can check this in operator_form to make sure we have a valid default set IF limit_operators is being used. Basically choose the first one form the remaining options.

1. +++ b/handlers/views_handler_filter.inc
   @@ -122,6 +122,8 @@ class views_handler_filter extends views_handler {
   +        'limit_operators' => array('default' => FALSE, 'bool' => TRUE),
   
   @@ -255,7 +257,12 @@ class views_handler_filter extends views_handler {
   +      $options['available_operators'] = !empty($options['limit_operators']) ? array_filter($options['available_operators']) : array();
   ...
   +        $options['limit_operators'] = array();
   

   I guess you actually want to use available_operations here? Otherwise the datatype is simply wrong

2. +++ b/handlers/views_handler_filter.inc
   @@ -282,6 +289,21 @@ class views_handler_filter extends views_handler {
   +      $limit = array_filter($this->options['expose']['available_operators']);
   

   Is there a reason to array_filter on both the submit handler and the actual executed code?

3. +++ b/handlers/views_handler_filter.inc
   @@ -282,6 +289,21 @@ class views_handler_filter extends views_handler {
   +      if (!empty($this->options['expose']['limit_operators']) && count($limit)) {
   

   limit_operators is a boolean, so we can treat it like that, don't we? The options system ensures that it is always available.

4. +++ b/handlers/views_handler_filter.inc
   @@ -481,6 +503,32 @@ class views_handler_filter extends views_handler {
   +        '#access' => count($operator_options) > 0,
   ...
   +      if (count($operator_options)) {
   +        $form['expose']['available_operators'] = array(
   

   I don't get, why we once use #access and otherwise and if to exclude if there are no operator options?

5. +++ b/handlers/views_handler_filter_numeric.inc
   @@ -187,29 +215,33 @@ class views_handler_filter_numeric extends views_handler_filter {
        if ($which == 'all' || $which == 'minmax') {
   ...
   +      if ($use_minmax) {
   

   Is there a simple reason why this condition is not part of the first if?

I didn't have much time, but here are those changes.

I think we might want some test coverage, I can have a look at this later on.

RE #40.5 - I think it does makes sense to check $use_minmax in there, but we can change the conditionals round like this. Better I think.

Added a quick test, but only to views_handler_filter_numeric.test.

Tested 873872-43.patch on Views 7.x-3.7 in Drupal Core 7.27.

As a short-term workaround for anyone who needs this functionality, this patch appears to meet those needs (with conditions).

Findings are as follows:

• Adds a checkbox to the VIEW "Limit Operators", but it does not initially list the operators to limit.
• Save View and then Edit View again. NOW, operators are listed with checkboxes.
• Save View. Only operators with checks show up in drop-down
• Edit View. Uncheck some operators and check new ones. Save View. Flush cache and hard refresh. Drop-down box does not refresh with the new options.
• Go back to edit the View and uncheck "Limit Operators". Save View. All operators are back in the drop-down.
• Edit View, recheck "Limit Operators". Change selected operators and the drop-down now reflects new changes.

If this is going to be added to the Module in the long-term, I would recommend (if possible): Have the "Limit the exposed operators" initially visible, but disabled. When "Limit Operators" is checked, then the options are toggled to be changed.

Hope to see that implemented one day...

Thanks for testing @tecchnomensch, I am not seeing any of the issues about that you describe. When I first add an exposed filter, the correct options are available. Also, when I update options, they are reflected straight away.

Thanks this patch works well for me, i think it should be committed.

Yes, I think I might just do that.. :P

Yeah why not, this is the question!

Yeah please do it.

If you promise to port that to D8, sure, commit it

Could this be committed please? There's been quite a lot of commits recently, mostly focused on internals, but this is an important piece of functionality, and for me it works perfectly.

My use case: I offer an exposed multi-select drop-down filter for users, with a choice of "is one of" or "is none of". Those are the only relevant operators. Offering all operators is just confusing. I would prefer not to resort to a patch just to get something essential like this.

I've never seen the issues reported in #44. I once encountered similar symptoms elsewhere, but they proved to be a Javascript or Jquery version conflict. I forget exactly what, but I realised I wasn't running recommended versions.

I found that the #43 patch did not apply cleanly to the latest dev build (7.x.3.x-dev+15).

Here's an update. Only changes are line numbers and the odd bit of context. No interdiff, as the interdiff command gets confused by such simple changes and the output is not helpful!

The rerolled patch in #54 applied cleanly to the latest 7.x-3.x-dev. Is there anything else that needs to be addressed?

I can't see anything outstanding with this. I've got so used to the functionality I'd forgotten it was still only a patch!

I'm going for RTBC.

Add another vote to enable this to the pile.

Seems like it needs a reroll?

Rerolled.

Committed. Thanks.

Thanks dagmar!