-
-
Notifications
You must be signed in to change notification settings - Fork 827
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix ambiguous column in search with ORDER BY #15899
Fix ambiguous column in search with ORDER BY #15899
Conversation
(Standard links)
|
6b3ef55
to
4686482
Compare
Surprisingly this doesn't seem to break anything, so marking as ready for review. I did an Note: There's a non-related, pre-existing issue in the activity search when sorting by activity status. |
@pfigel do you have any idea when this broke? |
(CiviCRM Review Template WORD-1.2)
@eileenmcnaughton @pfigel i think this should probably go into 5.20 thoughts? |
5.20 makes sense to me |
This fixes an issue where columns whose names are not unique in a search query cause a DB error when they're used as a sort column. The issue can be observed in the contribution search when sorting by contribution status. The issue is resolved by using the where field of the column spec, which holds the fully-qualified name of the column.
4686482
to
452a21f
Compare
@seamuslee001 @eileenmcnaughton breakage happened somewhere > 5.13 and <= 5.18. I rebased against 5.20. |
Cool - MOP based on @seamuslee001 review |
Overview
This fixes an issue where columns whose names are not unique in a search query cause a DB error when they're used as a sort column. The issue can be observed in the contribution search when sorting by contribution status.
Before
Contribution search fails with a DB error when sorting results by contribution status.
After
Contribution search can be sorted by contribution status.
Technical Details
The issue is resolved by using the where field of the field spec, which holds the fully-qualified name of the column.
Comments
I initially thought about fixing this by adding a special case for
contribution_status_id
somewhere, but then figured this would fix the general case. The downside is that it changes something quite central inCRM_Contact_BAO_Query
, so I'm having a hard time deciding on the trade-off.