URL List Filter Bug?

[rackem]

I have a URL list filter that is not behaving as expected. It is similar to some examples in the wiki and one that I use successfully already.

I've added "&fabrikdebug=1" to confirm the list query is correct initially, however, query does not "stick" when changing the number of records or changing pages in the list. I've troubleshooted it down to where it looks like there is a bug that breaks multiple filters on a single element.

The desired basic statement is: WHERE (p1 = 29 OR p2 = 29) AND (game = 2 OR game = 3).

More specifically, the following URL properly creates the query (highlighting added for clarity)
WHERE ( ( `mps_fargo_matches`.`p1` = '29' OR `mps_fargo_matches`.`p2` = '29') AND ( `mps_fargo_matches`.`game_id` = '2' OR `mps_fargo_matches`.`game_id` = '3') )

http://www.mypoolstats.com/index.php?option=com_fabrik&view=list&listid=33&resetfilters=1
&mps_fargo_matches___p1_raw[value][]=29
&mps_fargo_matches___p2_raw[value][]=29
&mps_fargo_matches___p2_raw[join][]=OR
&mps_fargo_matches___p2_raw[grouped_to_previous][]=1
&mps_fargo_matches___game_id_raw[join][]=AND
&mps_fargo_matches___game_id_raw[grouped_to_previous][]=0
&mps_fargo_matches___game_id_raw[value][]=2
&mps_fargo_matches___game_id_raw[value][]=3
&mps_fargo_matches___game_id_raw[join][]=OR
&mps_fargo_matches___game_id_raw[grouped_to_previous][]=1
&fabrikdebug=1


However, when the number of records or page is changed pages in the list, the query breaks into
WHERE ( `mps_fargo_matches`.`game_id` = '3' AND ( `mps_fargo_matches`.`p1` = '29' OR `mps_fargo_matches`.`p2` = '29') )

Note the logic of the query has changed - one part of the highlighted portion has disappeared and the parenthesis have changed!


So I began troubleshooting.

Here is a similar query that is working properly when the list changes (number of records or page is changed). The basic statement here is: WHERE (p1 = 29 OR p2 = 29) AND game = 2.

http://www.mypoolstats.com/index.php?option=com_fabrik&view=list&listid=33&resetfilters=1
&mps_fargo_matches___p1_raw[value][]=29
&mps_fargo_matches___p2_raw[value][]=29
&mps_fargo_matches___p2_raw[join][]=OR
&mps_fargo_matches___p2_raw[grouped_to_previous][]=1
&mps_fargo_matches___game_id_raw[join][]=AND
&mps_fargo_matches___game_id_raw[grouped_to_previous][]=0
&mps_fargo_matches___game_id_raw[value][]=2
&fabrikdebug=1

This produces
WHERE ( ( `mps_fargo_matches`.`p1` = '29' OR `mps_fargo_matches`.`p2` = '29') AND `mps_fargo_matches`.`game_id` = '2' )

When the list changes, the query is
WHERE ( `mps_fargo_matches`.`game_id` = '2' AND ( `mps_fargo_matches`.`p1` = '29' OR `mps_fargo_matches`.`p2` = '29') )

Note the order has changed but the logic is consistent.


Simplifying things further, I tried just WHERE (game = 2 OR game = 3) using this URL

http://www.mypoolstats.com/index.php?option=com_fabrik&view=list&listid=33&resetfilters=1
&mps_fargo_matches___game_id_raw[value][]=2
&mps_fargo_matches___game_id_raw[value][]=3
&mps_fargo_matches___game_id_raw[join]=OR
&fabrikdebug=1

This produces
WHERE ( `mps_fargo_matches`.`game_id` = '2' OR `mps_fargo_matches`.`game_id` = '3' )

When the list changes, the query is
WHERE ( `mps_fargo_matches`.`game_id` = '3' )

Note the first value has disappeared! This behavior matches what happened in the more complex query.


It looks like there is a bug that prevents multiple filters on a single element. I confirmed this behavior with a different element. It doesn't matter if OR or AND is used as the join. It seems like perhaps the array of values is being collapsed to only the last entry when the list is changed?

Note the parenthesis structure and statement order are also changing. That's not a problem of course if the logic is consistent, but it may be that is a related issue?

 

[cheesegrits]

Meh, this will be an absolute sod to track. That code is mind bogglingly complex. And I won't have time to get on it this week, I'm taking a few days off this week to visit family.

Remind me on Friday.

-- hugh

 

[rackem]

*friendly bump* Hope you enjoyed your time with family!

 

[cheesegrits]

Just got home. Will try and find some time over the weekend, although I've got a lot of catch up to do, having been out of pocket for 3 days.

-- hugh

 

[cheesegrits]

I spent a few hours on this last night. I've tracked down where the issue happens, but not making much headway on figuring out a fix. I'll have another go at it soon.

Notes to self ...

The problem raises it's head in the ist filter model, at line 1583 in getSessionFilters() ...

                    /**
                    * $$$ rob if the session filter is also in the request data then set it to use the same key as the post data
                    * when the post data is processed it should then overwrite these values
                    */
                    $counter = array_search($key, $postKeys) !== false ? array_search($key, $postKeys) : $this->counter;

... which means that although both of the OR'ed filter specs from the session are there, they have the same $key (the element name), and that key exists in the posted data (being preserved from the query string on the initial page load), so they both wind up using the same $counter as the array index when the filter data gets added to the main $this->filters[] array.

And part of the problem is that when the hidden fields are added for the original query string filters, in the list model, makeFilters(), line 6525 ...

$o->id = $elementModel->getHTMLId() . 'value'

... even thugh we have two instances of the element value, from the two query strings, they wind up with the same id. Which is why there's only one entry in that $postKeys array up there ^^ ...

But it's not as simple as just making sure the ids are unique in the hidden fields ...

-- hugh

 

[rackem]

Thanks for taking a crack at this Hugh. I've also been working at it but from a different angle - I just found a way to restructure my data so this complex filter is no longer needed and which also provides some other desired functionality.

So, the priority on a fix is lower unless it is affecting others.

 

[cheesegrits]

It's something I'd like to fix, but it ain't going to be easy.

--hugh

 

[rackem]

Understood. I'll close the thread; the info is here for posterity in case it comes up again.