A common feature/support request runs along the lines of "How do I filter this fields equivalence to this other field". For example, the most common variant of this is that a user may want all nodes with a CCK field equal to a user's profile field.

We could accomplish this by allowing the 'value' field to have an additional selector. Instead of just the typical value field, we could add all fields that are in the query (we would probably have to except pre_render and non-querying fields since they're pulling data differently) and simply put that fields field_alias into the query.

Obviously, this could not possibly work on exposed filters, but that actually makes it easier. If a filter is not exposed, we could put in a radio button that allows the user to select from fixed value or field. The field shows a select list. It might require some retooling of the existing handlers to allow this but perhaps an alternate query() method would be the easiest way to minimalize the impact on future development.

Files: 
CommentFileSizeAuthor
#89 vdc-699252.patch10.18 KBdawehner
PASSED: [[SimpleTest]]: [MySQL] 59,208 pass(es).
[ View ]
#86 vdc-699252-86.patch10.18 KBdawehner
PASSED: [[SimpleTest]]: [MySQL] 59,457 pass(es).
[ View ]
#86 interdiff.txt2.38 KBdawehner
#81 vdc-699252-81.patch10.18 KBdawehner
PASSED: [[SimpleTest]]: [MySQL] 59,052 pass(es).
[ View ]
#81 interdiff.txt712 bytesdawehner
#80 views-compare-erros.png80.47 KBhaydeniv
#78 vdc-699252-78.patch10.15 KBdawehner
PASSED: [[SimpleTest]]: [MySQL] 58,717 pass(es).
[ View ]
#78 interdiff.txt590 bytesdawehner
#76 699252.patch10.06 KBdawehner
PASSED: [[SimpleTest]]: [MySQL] 58,756 pass(es).
[ View ]
#76 interdiff.txt880 bytesdawehner
#75 field-comparison.png37.73 KBhaydeniv
#73 vdc-699252-73.patch10.04 KBdawehner
PASSED: [[SimpleTest]]: [MySQL] 57,309 pass(es).
[ View ]
#73 interdiff.txt795 bytesdawehner
#68 SubscriptionViewsComparisonCheck.txt11.54 KBnicxvan
#67 vdc-699252-67.patch9.26 KBdawehner
PASSED: [[SimpleTest]]: [MySQL] 56,674 pass(es).
[ View ]
#67 interdiff.txt4.8 KBdawehner
#64 Screenshot_27_06_2013_17_03-2.jpg123.4 KBemkay
#63 vdc-699252-63.patch9.69 KBdawehner
PASSED: [[SimpleTest]]: [MySQL] 57,862 pass(es).
[ View ]
#60 vdc-699252-60.patch9.67 KBdawehner
FAILED: [[SimpleTest]]: [MySQL] 57,762 pass(es), 2 fail(s), and 0 exception(s).
[ View ]
#60 interdiff.txt2.1 KBdawehner
#55 vdc-699252-55.patch9.68 KBdawehner
PASSED: [[SimpleTest]]: [MySQL] 57,430 pass(es).
[ View ]
#55 interdiff.txt1.06 KBdawehner
#52 views-7.x-699252-52-do-not-test.patch2.42 KBLes Lim
#50 vdc-699252-50.patch9.67 KBdawehner
PASSED: [[SimpleTest]]: [MySQL] 58,252 pass(es).
[ View ]
#46 vdc-699252-46.patch4.73 KBdawehner
PASSED: [[SimpleTest]]: [MySQL] 56,039 pass(es).
[ View ]
#22 views-fields_compare-699252-22.patch5.02 KBrudiedirkx
PASSED: [[SimpleTest]]: [MySQL] 1,603 pass(es).
[ View ]
#20 views-fields_compare-699252-20.patch4.54 KBrudiedirkx
PASSED: [[SimpleTest]]: [MySQL] 1,603 pass(es).
[ View ]
#9 699252-9-field_filter.patch6.11 KBinfojunkie
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 699252-9-field_filter.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#8 699252-8-field_filter.patch6.08 KBinfojunkie
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 699252-8-field_filter.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#4 699252-field_filter.patch5.14 KBdawehner
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 699252-field_filter.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

Comments

Issue tags:+views 3.x roadmap

tagging

It might require some retooling of the existing handlers to allow this but perhaps an alternate query() method would be the easiest way to minimalize the impact on future development.

We could add a if in the query method which calls another function. But this would need a lot of code changes for existing handlers.
So we have to execute it from the view::_build i guess.

To the design of the patch:

The field handlers gets a new method:

field_filter_alias:
return the field alias of the field, to be able to filter later.
returns FALSE if A the definition of the field data has a bit OR if the handler don't want it, for example views_handler_field_prerender_list
not sure yet about this returns TRUE for the admin settings, there might be no field alias at this point.

The filter handler gets new methods and settings:
query_field()
Attaches the query to filter by a field.
new settings: select the field to filter from, this will go over the existing fields of this display and checkwhether it returns a field_filter_alias

Thats it :)

Hmm. What if we add:

<?php
/**
* Determine if this field handler can be used to provide a value to filters.
*
* If this returns true, then $this->ensure_my_table() should set $this->field_alias
* which can then be used as a value for comparisons in the WHERE clause.
*/
function is_filter_value() { return TRUE; }
?>

Have this as TRUE by default. Have prerender_list set it to FALSE so that quickly eliminates most of the many to ones. Do a quick scan of other filter objects to see if any of them need to change their value.

Status:Active» Needs work
StatusFileSize
new5.14 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 699252-field_filter.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

Here is a initial hackish version

TODO:
Find out how to call another query method. Currently its a quite hacky bit of code:

  function query() {
    if ($this->options['field_filter']) {
      return $this->query_field();
    }

Any kind of suggestions are welcomed!

I had to move the build for filters under the build of fields.

thanks

I'll have a look

subscribing

StatusFileSize
new6.08 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 699252-8-field_filter.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

Updating the patch to the latest dev. No other work done on it.

EDIT: There's an extra dsm() call in there. Sorry!

StatusFileSize
new6.11 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 699252-9-field_filter.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

Updated my patch at #8 to handle cases where views_handler_field::get_field_alias() is called on an uninitialized handler. This happened when using a summary argument action.

subscribing

Subscribe

I do not have enough knowledge of the views module to make a relevant review of this patch, so I just tried to write a small module providing such a filter.

If you want to give it a try here it is : http://drupal.org/sandbox/david.fzs/1467698.

subscribing

Just tried david.fzs module in #12 and it work great. You should really just publish it as a full module.

Version:6.x-3.x-dev» 7.x-3.x-dev
Status:Needs work» Needs review

Doing some ticket cleanup - I will echo the sentiment in #14 - this functionality is really helpful in certain use cases and the david.fzs's sandbox module does the trick.

@merlinofchaos - do you think the sandbox code is a candidate for a merge? Seems to be a generalized enough function that it rightly belongs in views as opposed to an add-on module.

Marking needs review since there is working code for this use case that might be a candidate to merge in. Also marking 7.x.

Status:Needs review» Needs work

The last submitted patch, 699252-9-field_filter.patch, failed testing.

The sandbox module from david.fzs is perfect! Only the fields that already have been added to the fields are candidates. Perfect! I'm totally using this forever.

@merlinofchaos @dawehner You should just merge this in.

@david.fzs If they don't merge it in, promote it to a full module, like @haydeniv suggests.

@rudierdirkx
You totally get how opensource development works. In general we should first provide a patch against views, not an additional module,
and probably do some automatic testing for this feature, as you never want to break existing working views.

Yeah I get that =) Just saying: his solution is excellent, so let's use that one. No need to create it yourself.

I'll create a patch against 3.x-dev.

Status:Needs work» Needs review
StatusFileSize
new4.54 KB
PASSED: [[SimpleTest]]: [MySQL] 1,603 pass(es).
[ View ]

Cleaned up code and created a patch against 3.x-dev (f776088). All credits to @david.fzs.

It won't break existing Views, unless another module has defined data/filter [views][fields_compare] in which case the fields data collection from hook_views_data implementations will be corrupt. An acceptable risk IMO.

Status:Needs review» Needs work

If you would just not maintain all existing code ... it's really common in drupal to just commit code which is actually working fine.

+++ b/handlers/views_handler_filter_fields_compare.incundefined
@@ -0,0 +1,134 @@
+ function can_expose() {

Please use spaces instead of tabs.

+++ b/handlers/views_handler_filter_fields_compare.incundefined
@@ -0,0 +1,134 @@
+ * Implements views_object#option_definition().

should be better views_handler_filter::option_definition() or maybe overrides

+++ b/handlers/views_handler_filter_fields_compare.incundefined
@@ -0,0 +1,134 @@
+ '!=' => t('Is not equal to'),

Not equal should be probably <> instead.

+++ b/handlers/views_handler_filter_fields_compare.incundefined
@@ -0,0 +1,134 @@
+ if ($handler->table != 'views') {

In general we should find a better way to find out whether a field actually maps to a field in the database. This seems to be a dirty hack

+++ b/handlers/views_handler_filter_fields_compare.incundefined
@@ -0,0 +1,134 @@
+ $handlers = $this->view->display_handler->get_handlers('field');
+ if (!isset($handlers[$left], $handlers[$right])) {
+ return;

We should probably document what this code is doing.

+++ b/handlers/views_handler_filter_fields_compare.incundefined
@@ -0,0 +1,134 @@
+ $left_handler->set_relationship();
+ $left_table_alias = $this->query->ensure_table($left_handler->table, $left_handler->relationship);
...
+ $right_handler = $handlers[$right];
+ $right_handler->set_relationship();
+ $right_table_alias = $this->query->ensure_table($right_handler->table, $right_handler->relationship);

Can't we use $left_handler->table_alias directly?

StatusFileSize
new5.02 KB
PASSED: [[SimpleTest]]: [MySQL] 1,603 pass(es).
[ View ]

I don't know what this means:

If you would just not maintain all existing code ... it's really common in drupal to just commit code which is actually working fine.

I've updated the patch:

  • Tabs are now spaces.
  • Improved function comments: "Override" for inherited methods with the right parent class (always views_handler_filter in this case). Most Views classes and methods don't do this though...
  • Changed != to <>.
  • Ignore non-db-field handlers... There's currently no way to ask a field or filter handler if it's gonna use a database field. field, real_field, table etc don't mean anything until handler->query() is executed. I'm all for a better way (like adding a is_db_field() method to all handlers), but since there isn't any now... Something to think about for D8.
  • $left_handler->table_alias is empty at that point... Don't know why. After $this->query->ensure_table(...) it's still empty btw. Not connaisseur enough.

Status:Needs work» Needs review

Am I safe to apply this patch to my current views? Or has it been committed yet?

Thanks

Just applied patch...works excellent...LOVE!

Did this patch make into latest dev dated Oct 6?

Patch doesn't seem to work with date fields - unless I have something set wrong. Here's the query - (field_data_field_date_criteria.field_date_criteria_value > users_flagging.created)

I'm trying to compare a date type node field to the date a user was created. If I choose less than, all user's are showed. If I choose greater than, none are showed.

That's probably because field_data_field_date_criteria.field_date_criteria_value and users_flagging.created have different formats. field_date_criteria_value is probably a full datetime. created is a timestamp (int).

Sounds correct. Is there a way to compare with formats? I ran into this again yesterday - tried to compare a custom user field (tried decimal, integer, text) to a geocoded field. The geocode filed outputs miles or km in distance....but I assume this is just a format and your patch compares raw values? Is this correct?

I also tried to create a math field in views, multiply the miles by *1 and the compare math field to my custom field, but math filed wasn't an option for comparisons. It sounds like I'm wanting to compare formatted values not raw, and your code is for raw?

Thank you

FIXED

I apologize for my dumbness, but once the patch is applied, in the UI where do I find the options to make the comparison?

EDIT: I found the "global field comparison", now I have to understand why it says the handler is missing
EDIT 2: run update.php and way fine : )

@IWasBornToWin Yes, this patch compares raw values. Directly from the database. (Inside the database even.) There's also no way to reformat pre-comparison on the fly. That would require a query alter.

In case of date fields: if you always want to compare timestamps (int), you can create your date fields with that format. Date fields have 3 available formats I think.

About the patch: can someone test, review, verify & change status to rtbc?

Status:Needs review» Reviewed & tested by the community

patch works good.

Status:Reviewed & tested by the community» Needs work

There is an issue with pulling the fields through a separate sql query. This renders fields that are calculated in the view field after the initial query to throw an error. It would be better if the addition pulled the data value from the $row->data directly..

For example lets say you allow a user to view a gambit x number of times. Well the gambit only stores a value of the max number of views allowed. The field times viewed would effectively query the user and calculate how many times a user has viewed gambit. In this case, pulling the value from the row output would render the intended result. Under the current approach, you would get the following:

<?php
SQLSTATE
[42S22]: Column not found: 1054 Unknown column 'gambit.times_viewed' in 'where clause'
?>

@JMOmandown What you want is even more advanced and could be seen as an edge case. I think the last patch handles most of the cases, which would be a great improvement. You could create another comparison field for more advanced comparisons. Agree? Disagree?

While I do agree that it would require a great deal of structure change that arguably may not be worth the use case coverage, I don't think it is as far an edge case as you think. Comparing a value against a calculated value is pretty common among modules and would be as well among views if available.

The last patch does provide significant improvement! I may later, when I get sufficient time, delve into creating another comparison field for comparisons that steal the value from the view output and then filter (via ajax maybe) or at least a custom module as a place to start for others. However, I figured I'd bring up the procedural issue to you, who is much more familiar to the module, in case I was missing something.

@JMOmandown You mean the path from #22? Still all credits to @david.fzs, who created the module.

So, does is still need work?

Hi guys,

I'm trying to achieve the same thing, only that the left field is not being pulled from the database but rather is calculated based on some user input in an exposed views filter. Could someone tell me, theoretically, what I would have to do to achieve this.....

Thanks!

EDIT: Or i guess my question should be...how can I ignore the query process and do arbitrary calculations with the results of the left and right fields?

@el_toro You'll need hook_query_alter() or hook_views_query_alter() to add custom conditions. Do a get_class($query) to look up what methods it has in the api.

Hi rudiedirkx, thanks for the quick response.

Now being naive to the ways of views, this is how I'm expecting this to work.

1. I have the filter exposed with grouped filters.
2. When I set $this->value['value'] = $x; I'm expecting that the numerical field will be evaluated against $x and if the condition (e.g. > 5) is not satisfied then the row will be removed from the results.

Am I totally in the wrong domain here, in trying to achieve what I want?

EDIT: support request and code moved here http://drupal.org/node/1972146

@el_toro This isn't the issue/thread/place for a support request like that. This issue is about a db field comparison filter. You should create a new issue (and remove the code in your last comment). You can send me the link so we can talk about it there.

I assume this patch has never been committed to views? If I want to use latest version of views I need to reinstall patch after updating to latest views?

This patch is currently marked 'needs work' meaning that the community has deemed it not ready to be committed. This it not only hasn't been committed, but it won't be committed until someone is able to fix the patch (or remove the blocker that had it called needs work). The last move to needs work was in #33, so you should read that and the following comments to see what still needs to be done.

Thanks, I have zero knowledge on "fixing patches". Can I update to latest views and then reinstall the current patch that is working for me?

Status:Needs work» Reviewed & tested by the community

What @JMOmandown requested was too edge case and since @IWasBornToWin rtbc'ed it before, it's now rtbc again. Patch in #22 should work fine.

Project:Views» Drupal core
Version:7.x-3.x-dev» 8.x-dev
Component:Miscellaneous» views.module
Status:Reviewed & tested by the community» Patch (to be ported)
Issue tags:-views 3.x roadmap+VDC

I like the fact that this is implemented in a way that it can't break any existing view, so I committed it. Thank you very much! One less issue tagged with views 3.x roadmap :)

Committed and pushed to 7.x-3.x

I will port this patch to drupal 8 which requires for example a good test coverage.

Status:Patch (to be ported)» Needs review
StatusFileSize
new4.73 KB
PASSED: [[SimpleTest]]: [MySQL] 56,039 pass(es).
[ View ]

First totally untested version for drupal 8.

Where does FilterPluginBase come from? Shouldn't there be a use statement for that? (Technically maybe not if it's in the same namespace, but I think it's better to always explicitly use your classes (even global/root classes), but I don't know Drupal 8's coding standards, at all.)

It is in the same namespace already, so there is no need for the user statement.

+++ b/core/modules/views/lib/Drupal/views/Plugin/views/filter/Compare.phpundefined
@@ -0,0 +1,156 @@
+  protected function fieldOptions() {
+    $options = array();
+
+    $field_handlers = $this->displayHandler->getHandlers('field');
+    foreach ($field_handlers as $field => $handler) {
+      if ($handler->table != 'views') {
+        $options[$field] = $handler->adminLabel();
+      }
+    }
+
+    return $options;

This reminds me of DisplayPluginBase::getFieldLabels().

+++ b/core/modules/views/lib/Drupal/views/Plugin/views/filter/Compare.phpundefined
@@ -0,0 +1,156 @@
+    $snippet =
+      $left_table_alias . '.' . $left_handler->real_field .
+      ' ' . $this->options['operator'] . ' ' .
+      $right_table_alias . '.' . $right_handler->real_field;

I don't know that this is more readable...

StatusFileSize
new9.67 KB
PASSED: [[SimpleTest]]: [MySQL] 58,252 pass(es).
[ View ]

There we go, this time with a proper test!

Category:feature» task

+++ b/core/modules/views/lib/Drupal/views/Tests/Handler/FilterCompareTest.phpundefined
@@ -0,0 +1,119 @@
+    // Test the is great than operator.
...
+    // Test the is great than or equal operator.

greater, and I would put "is greater than" in quotes.

Otherwise, this is RTBC to me. And since its to maintain feature parity with D7, I'd call this a task.

StatusFileSize
new2.42 KB

Is it too late to consider also being able to compare a field against an argument value? I've drawn up a working patch against 7.x-dev to illustrate what I'm talking about, but haven't yet looked at what a D8 conversion would entail.

EDIT: it occurs to me that being able to compare fields to arguments isn't strictly necessary, since the same argument expression can also just be added to the view as a field. Nifty.

@Les Lim
This is a great idea in general, but please let us get this issue in drupal 8 first. Then we can backport the tests to be sure things still work.

@dawehner: of course!

StatusFileSize
new1.06 KB
new9.68 KB
PASSED: [[SimpleTest]]: [MySQL] 57,430 pass(es).
[ View ]

There we go.

Status:Needs review» Needs work
Issue tags:-VDC

The last submitted patch, vdc-699252-55.patch, failed testing.

Status:Needs work» Needs review
Issue tags:+VDC

#55: vdc-699252-55.patch queued for re-testing.

Status:Needs review» Reviewed & tested by the community

This is SO COOL and it has tests. And it keeps us up to date with D7

Status:Reviewed & tested by the community» Needs work

A couple of minor nits...

+++ b/core/modules/views/lib/Drupal/views/Plugin/views/filter/Compare.phpundefined
@@ -0,0 +1,140 @@
+    // Get the left table and field.
+    $right_handler = $field_handlers[$right];
+    $right_handler->setRelationship();
+    $right_table_alias = $this->query->ensure_table($right_handler->table, $right_handler->relationship);

You're getting the right table and field field here... although I would argue that the code is expressive enough and the comment is superfluous.

+++ b/core/modules/views/lib/Drupal/views/Tests/Handler/FilterCompareTest.phpundefined
@@ -0,0 +1,119 @@
+    // Test the inequality operator.
+
+    $view->initDisplay();

Unnecessary empty line (only because I'm setting this back to needs work)

Status:Needs work» Needs review
StatusFileSize
new2.1 KB
new9.67 KB
FAILED: [[SimpleTest]]: [MySQL] 57,762 pass(es), 2 fail(s), and 0 exception(s).
[ View ]

Status:Needs review» Needs work

The last submitted patch, vdc-699252-60.patch, failed testing.

Fatal error: Call to a member function setDisplay() on a non-object in /var/lib/drupaltestbot/sites/default/files/checkout/core/modules/views/lib/Drupal/views/Tests/ViewUnitTestBase.php on line 222

The other is random.

Status:Needs work» Needs review
StatusFileSize
new9.69 KB
PASSED: [[SimpleTest]]: [MySQL] 57,862 pass(es).
[ View ]

Oh we recently moved the test modules to tests/modules ....

Status:Needs review» Reviewed & tested by the community
StatusFileSize
new123.4 KB

I've tested this patch and all seems well. Screen shot attached.

Screen shot

I have tested this patch with a few combinations of float- and text-fields and tried to compare single- with multiple-value fields.

In my conclusion this feature/patch works very well but you have to know some properties about its behaviour:

It works as expected and self-declaring if you compare single-value fields with each other. If you use text fields which contain html-markup you should consider, that it treats html as content: "

abc

" is less than "

abc

"

If you compare a single-valued with a multiplevalued field with (e.g.) the condition "field left is less than field right", it will return TRUE, even if there is only one value in field right which is less than field left. In my opinion this is not a bug, but you must consider that this can lead to unexpected results.

If you compare two multiple valued fields with each other, the view will return one single record for each combination of having a less value in left field than in right field regardless of delta of field. E.g. you compare a field containting values "0", "1", "2" and "3" with "1", "2", "3" and "4" you will get 10 records as a result set.

So I think this feature works well, but is not advisable using with multi-instantiable fields.

P.S.
Before you can use fields to compare, you first have to select fields them. But that is normal views-behaviour.

Status:Reviewed & tested by the community» Needs work

This is looking good, and works nicely. Just a couple of things..

+++ b/core/modules/views/lib/Drupal/views/Plugin/views/filter/Compare.phpundefined
@@ -0,0 +1,140 @@
+    $field_options = $this->displayHandler->getFieldLabels();
+    // Filter out the views table as it will not be filterable.
+    foreach (array_keys($field_options) as $id) {
+      if ($this->view->field[$id]->table == 'views') {
+        unset($field_options[$id]);
+      }
+    }

We could just replace this lot with an array_map, it's fine how it is though really.

+++ b/core/modules/views/lib/Drupal/views/Plugin/views/filter/Compare.phpundefined
@@ -0,0 +1,140 @@
+    return check_plain(

This can use String::checkPlain()

+++ b/core/modules/views/lib/Drupal/views/Plugin/views/filter/Compare.phpundefined
@@ -0,0 +1,140 @@
+   * Build extra condition from existing fields (from existing joins).

Builds

+++ b/core/modules/views/lib/Drupal/views/Tests/Handler/FilterCompareTest.phpundefined
@@ -0,0 +1,117 @@
+    // Test the equality operator.
...
+    // Test the inequality operator.
...
+    // Test the is greater than operator.
...
+    // Test the is greater than or equal operator.

Do you think we should test the less than, and less than or equal operators too?

+++ b/core/modules/views/views.views.incundefined
@@ -122,5 +122,14 @@ function views_views_data() {
+    'help' => t('Compare database fields against each other.'),
...
+      'help' => t('Use fields comparison to filter the result of the view.'),

Maybe this should be 'Compare two fields to filter the result of a view', Also, can't we just ditch having help in the base array and in the filter array, and just go with the base?

Status:Needs work» Needs review
StatusFileSize
new4.8 KB
new9.26 KB
PASSED: [[SimpleTest]]: [MySQL] 56,674 pass(es).
[ View ]

As you have to unset values, this makes it indeed harder to read.

There we go.

StatusFileSize
new11.54 KB

I'm testing the patch in 7.x version and encountered a bug:

Not entirely sure this goes here or if I should change the version of the issue.

The use case I have in mind is check if a date on a node is between subscription dates set on a user.
I initially had one date field with an end date on the user, and checked to see that the subscription start was less than the node date. However when I checked to see if the node date was also less than the subscription end date I got no results. The test data is within the dates. I checked both configurations nodedate < subenddate and subenddate > nodedate but neither worked. I suspected that it was having trouble because the subscription was one date field so I separated it into two separate date fields.
However, checking against the first date works, but checking against the end date does not.

Even having the one filter on the end date returns no results.

Further testing both greater than and less than didn't return results.

I have a custom date format yyyymmdd and a sample of the data.

Node Date
20130529
Subscription Start
20130401
Subscription End
20140717

Plaintext version of the filter.
Subscription Start <= Node Date (Works alone)
Subscription End >= Node Date (Does not work)

Views export attached.

Status:Needs review» Reviewed & tested by the community

Looks good, reviewed #67, and my previous points have been fixed.

After further testing it's not checking the values, I have just the one compare fields filter checking that the date on the post is after the subscription start date and it shows all values ignoring the dates set on the nodes.

After even further tinkering it was user error, date fields weren't set as plain text. Setting them as plain text allowed the comparisons to work.

Status:Reviewed & tested by the community» Needs work

I think we're missing the associated config schema.

Status:Needs work» Needs review
StatusFileSize
new795 bytes
new10.04 KB
PASSED: [[SimpleTest]]: [MySQL] 57,309 pass(es).
[ View ]

I am sorry but I had to fix the combine entry at the same time.

@keyiyek, I'm having the same problem you did. Where is the global field comparison?

Thanks!

EDIT: Okay, I found it myself. The field that needs to be added as a filter is "Global: Fields comparison", not the fields you want to compare.

Thanks for all the work everyone has done on this!

Status:Needs review» Needs work
StatusFileSize
new37.73 KB

Just tested #73 on simplytest.me and checked "Global: Fields comparison" and then tried to "Add and configure filter criteria" and the spinner popped up for a second and disappeared but nothing happened.

Firebug says:

AjaxError:
An AJAX HTTP error occurred.
HTTP Result Code: 200
Debugging information follows.
Path: http://s046f22759f6cb8f.s2.simplytest.me/admin/structure/views/ajax/add-item/content/page_1/filter
StatusText: OK
ResponseText: Fatal error:
Call to undefined method Drupal\views\Plugin\views\filter\String::format() in /home/s046f22759f6cb8f/www/core/modules/views/lib/Drupal/views/Plugin/views/filter/Compare.php on line 100
response = conv( response );

field-comparison.png

Status:Needs work» Needs review
StatusFileSize
new880 bytes
new10.06 KB
PASSED: [[SimpleTest]]: [MySQL] 58,756 pass(es).
[ View ]

Thank you for the manual testing ... this time this should work.

I don't think it makes sense for this filter to have groupBy enabled?

StatusFileSize
new590 bytes
new10.15 KB
PASSED: [[SimpleTest]]: [MySQL] 58,717 pass(es).
[ View ]

Good catch.

Status:Needs review» Reviewed & tested by the community

+++ b/core/modules/views/lib/Drupal/views/Plugin/views/filter/Compare.php
@@ -0,0 +1,147 @@
+  protected function fieldsOperatorOptions() {

Not a part of this patch, but would be nice to tidy up how we deal with operators in filters, as it's generally all over the place.

Otherwise, I think this patch is good to go now.

Status:Reviewed & tested by the community» Needs work
StatusFileSize
new80.47 KB

Don't know if head is just broken right now because I had some issues with the installer but this is what I am getting right now when trying to compare fields.

views-compare-erros.png

Steps to reproduce:
SimplyTestMe Standard install
Try to edit the People View.
Try to Add a Global Compare field.

Status:Needs work» Needs review
StatusFileSize
new712 bytes
new10.18 KB
PASSED: [[SimpleTest]]: [MySQL] 59,052 pass(es).
[ View ]

Good catch, thank you!

Status:Needs review» Reviewed & tested by the community

The latest patch address the notice that came up in my testing and I tested against member for and last access which are date fields that had issues in the past that seem to be resolved now as well. Setting this back to RTBC as it was before I found my error and it looks like all other issues have been addressed. If bot is green, I think good to go.

Issue tags:-VDC

#81: vdc-699252-81.patch queued for re-testing.

Issue tags:+VDC

#81: vdc-699252-81.patch queued for re-testing.

Status:Reviewed & tested by the community» Needs work
Issue tags:+Needs tests

The issue exposed by #80 shows that there is untested code being added by this patch. The UI form being added needs to be tested by a WebTest.

Status:Needs work» Needs review
Issue tags:-Needs tests
StatusFileSize
new2.38 KB
new10.18 KB
PASSED: [[SimpleTest]]: [MySQL] 59,457 pass(es).
[ View ]

The issue exposed by #80 shows that there is untested code being added by this patch. The UI form being added needs to be tested by a WebTest.

We are all friends ...

Status:Needs review» Needs work
Issue tags:-VDC

The last submitted patch, vdc-699252-86.patch, failed testing.

Status:Needs work» Needs review

#86: vdc-699252-86.patch queued for re-testing.

Issue summary:View changes
Issue tags:+VDC
StatusFileSize
new10.18 KB
PASSED: [[SimpleTest]]: [MySQL] 59,208 pass(es).
[ View ]

Let's see whether it still applies.

This looks nice, lets get it in :)

I sadly can't get the actual D7 patch to work, has this been tested? Because it doesn't work as a contextual filter, therefor you can't actually do the use case described in the summary. Of depending what page you are on filtering the list. I am for example comparing two date fields, to show the files of only that day. These are two different content types.

Some minor suggestion.

  1. +++ b/core/modules/views/config/schema/views.filter.schema.yml
    @@ -25,6 +25,24 @@ views.filter.bundle:
    +        - type: string

    I don't think hyphen is required here.

  2. +++ b/core/modules/views/lib/Drupal/views/Plugin/views/filter/Compare.php
    @@ -0,0 +1,148 @@
    +   */
    ...
    +   * Builds extra condition from existing fields (from existing joins).
    ...
    +   *
    ...
    +   * {@inheritdoc}
    ...
    +  /**

    I don't think we can mix these two yet.

  3. +++ b/core/modules/views/lib/Drupal/views/Tests/Handler/FilterCompareTest.php
    @@ -0,0 +1,121 @@
    +
    +

    Extra white space.

+++ b/core/modules/views/views.views.inc
@@ -128,5 +128,13 @@ function views_views_data() {
+    'help' => t('Compare two fields to filter the result of a view'),

As nitpicking is already happening, Full stop.

Aside from that, I think this is ready to go.

Wonderful! Thanks to all patchers and testers, this is excellent work.