Feature #12866

Make access points sort alphabetically by default on view and edit pages

Added by Dan Gillean over 2 years ago.

Status:NewStart date:03/06/2019
Priority:MediumDue date:
Assignee:-% Done:


Target version:-
Sponsored:No Tested version:


Right now in AtoM, terms linked to records as access points will display in the order the are added and/or created during an import. Often this order is arbitrary, and in a long list it can make user discovery more difficult.

This proposal would be to add logic to AtoM to automatically sort linked terms alphabetically on view pages, and in edit pages on first load (new terms added while in edit mode will not automatically sort into a list of previously linked terms - they would be re-ordered on save).


There are some challenges and considerations that would need to be taken into account. The first is the number of places we would have to review and make changes in AtoM for consistency. The primary focus of this ticket is on access points, but there are also many other fields with a similar behavior that should at least be considered for consistency. This list is not comprehensive, but should give us a starting place for analysis - default sort changes would include the following:

  • Subject, place, genre, and name access points
  • Languages and scripts of material
  • Languages and scripts of description (control area)
  • Creator names?
  • Related descriptions?
Authority records
  • Subject and place access points
  • Actor occupations
  • Standardized, Parallel, and Other forms of name?
  • Languages and scripts
  • Related actors?
  • Related resources?
Repository records
  • Repository type
  • Parallel and Other forms of name?
  • Languages and scripts
  • Thematic area access points
  • Geographic sub-region access points
  • Parallel and Other forms of name?
  • Languages and scripts
  • Related functions, authority records, and/or resources?

Additionally, consideration must be given to how this will behave in a multilingual environment when culture fallback is in place, and not all strings have data in the current display language. Finally, the effects on performance and scalability will need to be accounted for as well - this will lengthen save and possibly load times, and should not be implemented if it is likely to lead to page view timeouts, etc.

Also available in: Atom PDF