Allow additional field-to-field conditions with the default views_join handler

Can you please create a real patch? This would really help to bring this issue further.

I'm wondering whether this feature might be helpful on 6.x-3.x, too.

Ok, this looks reasonable to me. CanI get one for 6.x-3.x too?

I'm sorry but the patch doesn't apply anymore against 7.x-3.x

Man what a long night :)

Subscribe to this issue because i would like to have this issue in

For #1451714: Extend content flag relationship with specific user relation I had a similar use case, and for the moment had to resolve that by using extra as a string and not an array.

fubhy, I reapplied your patch and extended it with left_table (it might be needed sometimes).
Additionally I added a formula info, so more complex on clauses could be managed.

Examples:

array(
  'field' => 'name',
  'formula' => 'LOWER(mytable.name)',
),
array(
  'formula' => 'TRIM(%alias.name) = TRIM(mytable.name)',
),

fubhy, dereine, do you think this will be a useful addition.

Sure, additional documentation was needed for the new functionality.

Views in drupal6 has

 *   - - raw: If you specify raw the value will be used as it is, so you can have field to field conditions.

as a special flag in the extra array. It would be cool if there could be some kind of consistency here. Sorry for not remembering that, though this was added in hurry.

Triggering the testbot.

Oeh I really, really want this. I tried to do this 14 different ways without this patch and nothing worked. There's no way to pass a formula/expression to the query builder?

additional-field-to-field-conditions-1090432-11.patch works perfectly, both the 'left_field' + 'left_table' and 'formula' approaches.

@derhasi , your patch #11 contains 2 files. Which is the one to apply?

@johnv additional-field-to-field-conditions-1090432-11.patch worked for me. (The first, big one.)

If it's a simple join, use can use left_field and left_table. Otherwise, use formula.

That's the one.

Refactor patch from #11 against current code repo. Works for me with 7.x-3.8.

Patch in #11 applies correctly and functions correctly in most recent git dev as of 2015/03/18.

We've recently switched our testing from the old qa.drupal.org to DrupalCI. Because of a bug in the new system, #2623840: Views (D7) patches not being tested, older patches must be re-uploaded. On re-uploading the patch, please set the status to "Needs Review" so that the test bot will add it to its queue.

If all tests pass, change the Status back to "Reviewed & tested by the community". We'll most likely commit the patch immediately without having to go through another round of peer review.

We apologize for the trouble, and appreciate your patience.

Thanks.

Hey @colan - there is a bug in this patch when using an "IN" operator with only 1 value. NOt sure how to exactly proceed other than to note that the port to D8 should take note of this. I just posted an issue and patch (related: "Extra join conditions fails with 1 value using IN condition (2656852)". It involves adding a single line of code (patch snippet below).

@@ -1599,6 +1599,7 @@ class views_join {
                 $operator = $info['operator'] == 'NOT IN' ? '!=' : '=';
               }
               $info['value'] = array_shift($info['value']);
+              $info['operator'] = $operator;
             }

             if (is_array($info['value'])) {

I have the problem mentioned in #26 also (with NOT IN filter).

The commit breaks existing sites with NOT IN filters. I suggest to revert it and find a non-destructive solution.

@maximpodorov I agree with you. Do you mind moving the issue back to views itself?

So the reverting patch is OK now.

There is a backport of the D8 version of views for supporting left_tables #2642100: views_join doesn't allow extra conditions on left table but this patch does not apply now because of this issue.
Because of last comment I don't know if this commit will be reverted or not, so I need to roll the patch or wait. thanks!

This introduced a regression that breaks all JOINs. Please create a new STABLE views release asap.

After upgrading from 7.x-3.11 to 7.x-3.14, I bisected views down to this issue that was breaking my filters. In my case I have a field being used in a AND/OR condition group, with the field existing on one bundle but not the other. Reverting this patch fixes my filters.

Will post further details of the bug if I come across it.

Attached is a revert patch.

@Sam152 I think you just need the --relative flag on git when you created that patch from in the views folder in your project.

Hand-fiddled patch.

Reverting something that's already released... Is that a thing? I don't know what the issue is exactly, but the solution is being worked on in #2656852: Extra join conditions fails with 1 value using IN condition I think..

If a patch only causes issues we typically revert it.

A fairly large and complicated patch committed with no tests? Two bugs caused by this change have been raised, are those are the only ones out there?

This introduced a regression that breaks extra with zero value #2791353: JOIN 'extra' fails with zero value

Another problem report that looks to be related: #2754667: "In none of" (= Off/0) filter operator stopped working after Views update to 7.x-3.14 .

Wondering if any action is planned on this? I manually patched the security vulnerability in June and have since been holding out for 3.15.

Reverting this patch also fixed a problem introduced by 3.14.. Please commit the revert, until a test+fix can be committed again.

For about 7 months a broken views release is shown on project home. Are the maintainers alive?

Here's another re-roll of the reverting patch against today's security update (7.x-3.15).

A related fix for #2754667: "In none of" (= Off/0) filter operator stopped working after Views update to 7.x-3.14 was included in the release (commit) but I'm not feeling 100% confident it fixes all problems.

I pushed the revert patch now. Thank you, well let's see whether someone is willing to work on the issue itself.

Thanks a lot, @dawehner. Does it make sense to start by recreating the originally committed patch (for 7.x) with change in 63e1d67c7 and mark it "needs tests"?

@othermachines, it would. Make an interdiff between the new patch and the patch in #22. However, keep it at "Needs work", as this breaks a lot more than just the "none of" fixed in #2754667: "In none of" (= Off/0) filter operator stopped working after Views update to 7.x-3.14 . It breaks also NOT IN filters (#26, #27, #29 and #30) and apparently also field being used in a AND/OR condition group (#38].

Sorry, I lost track of this. Here is a re-roll of originally committed patch in #22 plus fix from #2754667-2: "In none of" (= Off/0) filter operator stopped working after Views update to 7.x-3.14 . This needs work; see @jcnventura's comment in #54.

I don't think this qualifies as critical now that original commit has been reverted.