(dev/core/98) FGB Searching by any Address fields with location type other than primary throw DB error

[monishdeb]

Overview

Steps to replicate:

1. Go to Search Builder
2. Choose Contact >> Street Address (or any address field) >> Home (as location type) >> NOT EMPTY (or any other operator)
3. Submit
   See the result under BEFORE

Before

After

Technical Details

I would say this is a regression due to this change fbbd2be#diff-e54381bfdf51e31cab376c71ca0d66ffR4895
The change was earlier made to fix FGB error as per which SELECT columns must have all those column(s) that are present in GROUP BY clause. But in certain case, we only want a predefined set of (formatted) column like in this case UPPER(LEFT(contact_a.sort_name, 1)) as sort_name irrespective of what's there in GROUP BY, we need to disable FGB to allow such query to pass.

[monishdeb]

ping @eileenmcnaughton @lcdservices @seamuslee001

[eileenmcnaughton]

This seems very safe to me & once we get a test box that runs in fgb mode it will block further regressions on this chunk

[monishdeb]

Also fixes https://lab.civicrm.org/dev/core/issues/95

Test this patch on test build http://core-12074-qesz.test-ubu1204-5.civicrm.org/ (pradmin/pradmin1234)

[eileenmcnaughton]

2 bugs one fix = yay

[monishdeb]

merging as per tag

[eileenmcnaughton]

@monishdeb @totten - this appears to be a regression in 5.1 caused by a full group by search fix. I would say it would probably rise to the level of being worth a 5.1.1 code drop next week - but at the very least it should be included if anything else triggers that drop.

In the meantime, @monishdeb - can you please do a PR against the 5.2 rc since this missed that & should be in that at the very least

[monishdeb]

@eileenmcnaughton here's the 5.2 rc PR #12081