Important: Remaining unordered queries now order by uid 

Description 

The sweep that ordered the unordered profile queries (see Important: Unordered profile queries now order by uid) missed five query paths, which kept returning rows in whatever order the database yielded:

  • ContractRepository::findAll() , which builds every contract select item in the backend (TCA itemsProcFunc and FlexForm)
  • ContractRepository::findByUids() , which resolves the contracts of the "selected contracts" plugin
  • ProfileRepository::findByUids() , which resolves the profiles of the "selected profiles" plugin
  • ProfileRepository::findByFrontendUser() , which resolves the profiles of a frontend user for the frontend editing of academic_persons_edit
  • ProfileRepository::findByDemand() with a non-empty demanded ordering — the list plugin's Sort by — which carried no tiebreaker, so profiles equal in it (two people sharing a last name) had no defined relative order

The first four now order by uid ascending; the demanded ordering keeps winning and gets uid ascending appended as a tiebreaker.

Three further methods ordered by sorting alone: AddressRepository::findByContractIncludingHidden() , EmailRepository::findByContractIncludingHidden() and PhoneNumberRepository::findByContractIncludingHidden() , which list the contact records of a contract for the frontend editing. Records an editor never reordered share a sorting value, and their relative order was whatever the database yielded. All three now append uid ascending as the tiebreaker.

Impact 

No visible change is expected: uid ascending is the order every supported database returned in practice, it is simply guaranteed now rather than coincidental.

For the two uid selection methods the order of the editor's selection is deliberately not reproduced — in() does not preserve it, and it was never delivered before. Honouring the selection order would be a behaviour change beyond making the lists reproducible.

Affected Installations 

Every installation of this extension.