dbjoin front end select does not use the set "where/orderby" clause

[p38]

If you have a font end select option for the element databasejoin set, and have a where/orderby clause, the list that pops up for selection does not implement the where clause.

This makes it pretty much unsuable as most lookups would have some type of where/order by clause.

Paul

 

[cheesegrits]

Testing this here.

-- hugh

 

[cheesegrits]

Hmmm. Yeah. Interesting.

Still working on it.

-- hugh

 

[cheesegrits]

OK, unless I'm missing something obvious, we just don't even try. We just build the list, subject only to pre-filters (we do a resetfilters=1 when we open the list).

It looks like we have a mechanism for elements to add to the list's main getData() query, but we don't have anything in the join element model which does it.

It would also be kind of tricky to implement, as a lot of join WHERE queries are likely to involve element placeholders from the same form, so we'd have to pass the full form data from the form being displayed, and pass it in to the list view.

Hmmmm.

Going to rise a ticket on this one.

-- hugh

 

[rob]

Yeah I've looked previously and decided that the db join where is just too flexible to be correctly applied to the list query. My suggestion is to use a copied list with the same prefilter logic applied as the dbjoin element and set that list to be the one that the plugin uses to select records from.

 

[p38]

thanks guys, I understand. Perhaps you can add something in to hint to warn the developer that the list does not apply the where clauses, so we dont think it is a bug.

Paul

 

[cheesegrits]

Done.

https://github.com/Fabrik/fabrik/commit/d3854cdab7d763f38193134c312f5f27d6a8495a

-- hugh