Bug with filtering: "exact match" does not apply

[jfquestiaux]

I have a list with one of the column displaying names from another list.
This is done with a databasejoin element. This works fine.

I use filters to search the list. The names being pull with a join, it's actually ID that are search in the query and, however "Exact match" is set on "Yes", the search is done on "%ID%" instead of just "ID":
...LEFT JOIN `contacts` AS `contacts_3` ON `contacts_3`.`id` = `troncons_baliseur2`.`contact_id` LEFT JOIN `contacts` AS `contacts_4` ON `contacts_4`.`id` = `troncons_baliseur1`.`groupe_baliseur` LEFT JOIN `contacts` AS `contacts_5` ON `contacts_5`.`id` = `troncons_baliseur2`.`groupe_baliseur` WHERE ( `troncons_baliseur1`.`contact_id` LIKE '%5%' ) ORDER BY `troncons`.`nom_troncon` ASC

In the example above, this returns all the contacts that have "5" in their IDs instead of just contact #5, so the list is filtered but with confusing result.

 

[jfquestiaux]

Friendly bump.

My client would like to have a fix for this because it is really confusing when you search something.
The latest GitHub update is from April 15th, but I don't think recent addtion would address this issue.

 

[cheesegrits]

Can you post a screenshot of you join element's setting, witht he list settings tab visible?

I just tested this, with a join element with filtering set to dropdown. exact match, and it uses =, not LIKE:

WHERE ( `fab_events`.`state` = '1' )

Here's a screencast ...

http://screencast.com/t/fDLyb4En

-- hugh

 

[jfquestiaux]

Hi Hugh,

Yes it works with dropdows, but not with autocomplete rendering (I have not tested with the other options).

 

[cheesegrits]

And again ...

Can you post a screenshot of you join element's setting, witht he list settings tab visible?

-- hugh

 

[jfquestiaux]

Sorry about that.
here are the settings:

 

[cheesegrits]

OK, confirmed. I see where the problem is, but it's not going to be an easy fix. Raising a github issue, so I can get an assist from Rob, but that may be a while.

https://github.com/Fabrik/fabrik/issues/1241

NOTES ...

In getFilterCondition() in the element model, called from getFilterHiddenFields() when the filters are being built for display, we do:

        if ($this->getElement()->filter_type == 'auto-complete')
        {
            $cond = 'contains';
        }
        else
        {
            $match = $this->isExactMatch(array('match' => $this->getElement()->filter_exact_match));
            $cond = ($match == 1) ? '=' : 'contains';
        }

... overriding whatever 'match' is set to in the element params on initial list page load. That goes in the hidden field which submits with the filters, and overrides 'match' when the filters get applied.

While this is correct behavior for anything else, it's obviously not right for a join. However, I don't think just overriding getFilterCondition() in the join model and not doing the 'contains' thing is a fix. I think we need to apply some more intelligence when the filters are actually submitted.

jfquestiaux - you could try overriding the method, by copying that getFilterCondition() in to the join element model, and removing the code that tests for auto-complete, so it always obeys the 'match' param. I'm pretty sure this will break other usage of auto-complete, but it's worth a go ... if only as a bandaid for this client's site.

-- hugh

 

[jfquestiaux]

Thanks for the pointers.

Actually, I just modified the getFilterCondition() in the elment model as follow:

protected function getFilterCondition()
    {       
        if ($this->getElement()->filter_type == 'auto-complete' && $this->getElement()->plugin != 'databasejoin')
        {
            $cond = 'contains';
        }
        else
        {
            $match = $this->isExactMatch(array('match' => $this->getElement()->filter_exact_match));
            $cond = ($match == 1) ? '=' : 'contains';
        }
 
        return $cond;
    }

and now the filter works as expected.
I haven't seen any adverse effects (yet).