Details
-
Type: Bug
-
Status: Open
-
Priority: Minor
-
Resolution: Unresolved
-
Affects Version/s: 4.7.13
-
Fix Version/s: None
-
Component/s: CiviCRM Search
-
Labels:None
-
Versioning Impact:Patch (backwards-compatible bug fixes)
-
Documentation Required?:Developer Doc
-
Funding Source:Needs Funding
Description
Problem behavior
Custom searches have the capacity to define ad-hoc SQL, including an ORDER BY clause, in the all() method. This has the effect of ordering search results, and that order is preserved on tasks such as printing Mailing Labels.
The Mailing Labels form includes an option to "Merge labels for contacts belonging to the same household". When this is selected, the ORDER BY defined in the custom search is lost. (As of CRM-16838, the contacts are re-ordered by sort_name; and before that the households were simply appended to the end, unsorted.)
Essential limitation
Household merging is done by CRM_Contact_Form_Task::mergeContactIdsByHousehold(), but there's currently no way for this method to know about ORDER BYs defined by custom searches.
Possible solutions
1. A standard method orderBy() could be added to custom searches (i.e., in CRM_Contact_Form_Search_Interface), and mergeContactIdsByHousehold() could call that tp get an ORDER BY clause after merging households. However, since mergeContactIdsByHousehold() just deals with an array of contact IDs, I'm not sure that the ORDER BY clause would be helpful here.
2. It's conceivable that a standard method sortContacts(&$contactIds) could be added to custom searches (i.e., in CRM_Contact_Form_Search_Interface), and mergeContactIdsByHousehold() could call that method to re-order contacts after merging households. This method allows ad-hoc sorting of an array of contact IDs.
3. Another hook? (seems unnecessary)