Using a custom filter group breaks the filter grouping UI

This is related to #1367304: Using OR in filters breaks contextual filters.
I'm postponing until that's resolved.

any fixes for similar problem in D6?

There are still stray references to date_group in some of the handlers, shouldn't those be replaced or removed?

Of the two choices in #1, I prefer the one where you name the group. That is consistent with the way other things in Views work, like the naming of filter and pager keys.

The date filter was deliberately kept separate from the other filters so you could OR or AND the individual date fields without regard for the way the other filters were connected. I don't know that I understand why we would want to lose that, nor do I know any other way to accomplish that goal.

I was able to solve the problem described in the original post by editing the setting for the date field, and changing the method. It's all the way at the bottom below the list of available date fields.

However, there is a bigger problem here. Views now has the ability to regroup filters, but specifying a group prevents the UI from working. AFAIK, there is no way for Views to avoid this, making it squarely Date's problem.

This approach just concatenates all of the appropriate conditions together and adds it back into whatever group is chosen with the UI.

Obviously it needs a better name than 'clean_up_query()' :)

#9: date-1399744-9.patch queued for re-testing.

At first glance the difference between op_simple and op_between was not clear, until I realized they were identical except for the parent:: call.

So I consolidated into a helper function, documented it, and also was able to remove the 1=1 hack from #1096246: Filters not being applied correctly.

I'm generally against indirection, but this is very clear to me, since the code flow is identical for both ob_between and op_single.

I'm happy with this, idflood says it fixes his problem, any objections KarenS?

One thing that is left out of the new code is the elseif() clause from the following:

        if ($field['table_name'] != $this->table || !empty($this->relationship)) {
          $this->related_table_alias = $this->query->queue_table($field['table_name'], $this->relationship);
        }
        // $this->related_table_alias gets set when the first field is processed if otherwise empty.
        // For subsequent fields, we need to be sure it is emptied again.
        elseif (empty($this->relationship)) {
          $this->related_table_alias = NULL;
        }

This was only on the between op and unfortunately I didn't document it very well. I remember I had a problem with some combinations of dates that did and did not use relationships without that fix. But I can't replicate any problem now with the new code that is missing that clause. Basically I'm documenting here that we've lost that clause in case we find later that it is still needed.

Other than that this looks like a very elegant solution to the problem. Since I can't find a way to trigger a problem from the missing elseif() clause, I'm going to call this good.

Thanks!

http://drupalcode.org/project/date.git/commit/6a3828f