Bug #13562

Place terms added via Events dialogue do not show up in term view page browse results

Added by Dan Gillean about 1 month ago.

Status:NewStart date:09/01/2021
Priority:MediumDue date:
Assignee:-% Done:


Category:Taxonomy / Term
Target version:-
Google Code Legacy ID: Tested version:2.5, 2.6, 2.7
Sponsored:No Requires documentation:Yes


Templates such as RAD that use the events dialogue allow users to associate a place term with an event via an autocomplete. However, once linked, users have no way of seeing these term relations via the term and taxonomy browse pages - the only way the system alerts a user is if they try to delete a term linked to a description via an event (at which point a warning about the relation is shown). This means that adding place terms is not currently useful for discovery. This issue ticket proposes to either fully integrate the event Places terms with the rest of the view page discovery elements, or else change the event Places field to a free-text field and no longer associate it with the Places taxonomy.

To reproduce

  • Log in as an administrator
  • Navigate to Admin > Settings > Default templates, set the default description template to RAD, and save
  • Start creating a new archival description
  • In the Dates of Creation area, use the event dialog to add new dates of creation. Include a new place term in the event Place field. Save.
  • Navigate to Browse > Places, find your new term, and click through to the term view page

Resulting error

The description with the related event place term is not returned in the related description browse results on the term view page

Expected result

Place terms added via the Events dialog should be included in related description results on term view pages, or else the event Places field should be a free text field.


I believe that the issue is due to how the relation is stored in the database. There are separate tables for events that link creators to descriptions - we describe this in the documentation like so: 

In AtoM’s data model, an archival description is a description of a record, understood as the documentary evidence created by an action - or event. It is events that link actors (represented in AtoM by an authority record) to archival descriptions - see Entity types for more information.

In the term view pages, AtoM is checking for direct relations between a taxonomy term and a description (or authority record), such as those created when linking an access point to a description. Because eventPlaces are technically a relation between an event and a term, the related description browse results on the term view page does not currently show them. 

Currently, any related event place is also not showing up in the right context menu of the description view page under the "Places" heading, nor is it a hyperlink in the Dates of creation part of the description view page. If we decided to fully integrate these terms, we might consider making these changes as well, but adding an event qualifier as we do with related names - e.g. "My place term (creation)."

This has been discussed in the user forum in 2019, and again recently in 2021. See:

The 2019 thread includes a lot of interesting discussion on possible fixes. Note however that at least one user has pointed out some RAD standards references that should be considered during implementation:

I think that the 'events place' field should enter the information as it appears in the source (the document) :
« RAD Rule “For an item, transcribe the place of publication, distribution, etc., in the form and grammatical case in which it appears.” (RAD 1.4C1). »
On the contrary, the places taxonomy and 'Place access points' should be used for standard terms.

This is a big problem because AtoM confuses the fields and thus creates unnecessary duplicates.
The data entered in the 'events place' field should not be moved to the taxonomy field.

As such, one possible solution for this issue is to make the event Places field free-text rather than fully integrating it into the Places taxonomy. Note that careful consideration would need to be given to how schema migrations can handle user data during upgrades if we take this approach.

Also available in: Atom PDF