Generated Finding Aid PDFs only shows physical storage location field

Skip to first unread message

Sandra Yates

Nov 11, 2021, 12:10:54 PM11/11/21
to AtoM Users


We’ve noticed an issue with the generated finding aids since the last major update to 2.6. See example links below.

Currently, the PDFs only provide the data from the Physical Storage Location field. Our use of that field is very general, mostly linking containers to collections. Can the finding aids list the Physical Storage Name field, so Physical Storage Name field (such as Box and Folder numbers) is visible like in previous versions? Is this a known issue? I didn't notice it listed under Finding Aid Issues or mentioned previously in the forum.

Generated Finding Aid, 2.5.3 (has container column):

Generated Finding Aid, 2.6.4 (only has Physical Location): 

Thank you for all your help!


Sandra E. Yates, MSIS, CA, DAS (she/her) Head of McGovern Historical Center Texas Medical Center Library

Dan Gillean

Nov 12, 2021, 4:37:47 PM11/12/21
to ICA-AtoM Users
Hi Sandra, 

Good catch, and thank you for bringing this to our attention for consideration. 

There were definitely some finding aid layout changes introduced between 2.5 and 2.6, captured in this issue ticket: 
This work started as a community pull request that turned into a sponsored development project for Artefactual to finalize the implementation. While replacing the container information with physical description information in the table rows of the inventory summary layout was discussed (and moving the storage information to below the table), I don't recall us intending to change the *type* of storage information included - this may be a bug or intended outcome of the changes. 

I have reached out to the original sponsor of the changes to ask if there was a rationale for such a change that I no longer recall, or whether this was accidental. AtoM does already have a method for users to exclude physical storage information from finding aid (basically: hide storage info via Admin > Visible elements; set finding aids to Generate as public user in Admin > Settings > Finding aid - and then no storage information should appear), so I personally don't think adding this information back in poses any increased privacy or security risk, but I wanted to make sure there isn't some reason I am failing to consider / remember from the original development project. 

From the response I've received back, it sounds like this was a local convention based on how the sponsoring institution uses the storage module and the description identifiers, and was something in the original community pull request that our team at Artefactual didn't catch, rather than a purposeful change we implemented as part of the finding aid layout improvements. 

Correspondingly, I have filed an issue ticket for this, so we can track it: 
Any development work related to this bug fix is not currently sponsored, so I can't guarantee any related change will be included in a future release, most notably 2.7 since we are slowly trying to wrap that up and prepare it for public release. That said, we do try to tackle as many bug fixes as we can before a major public release, so hopefully we can address it in the future. Otherwise, I will update the thread if I hear back from the original sponsor as to any rationale. 

In the meantime, I'm not personally very familiar with working with XSLTs, but if you have someone on staff who is, you might be able to compare the 2.5 finding aid XSLT and the 2.6 ones, and make some local changes to your XSLT file to re-add the container info using this. 

The AtoM EAD 2002 XML export of an archival unit (e.g. fonds, collection, etc) is used to generate finding aids - it is transformed into a PDF via our XSLT files: 
You can always perform an EAD export yourself to see how AtoM structures the storage information, but here's an example from our demo site: 

<physloc id="physloc0004">Processing Room B</physloc>
<container type="shelf" parent="physloc0004">DD-10/11/12/13</container>

The EAD <physloc> element captures location information, while the <container> element has the actual container info. We use attributes in each element to keep them related - a unique incrementing @ID attribute in the physloc element, with a @parent attribute using the same ID in the <container> element. 

Hopefully by looking at how the container info was added in 2.5 you can make some local adjustments to your current XSLT until we can address this in a public release. 

Regards ,

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
he / him

You received this message because you are subscribed to the Google Groups "AtoM Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
To view this discussion on the web visit

Sandra Yates

Nov 15, 2021, 6:10:12 PM11/15/21
Hi Dan,

Thank you for your response. The links you shared were very helpful. I compared the ead-pdf-inventory-summary.xsl file in 2.5 and 2.6. The big difference related to ead:physloc and ead:container seems to be in some new coding in 2.6 XSLT around lines 1599 and 1667 where mode="itemDsc".

I have a very simplistic approach to XSLT. My first thought is to just add the ead:container after ead:physloc.
~line 1599  add <xsl:apply-templates select="ead:container" mode="itemDsc"/>
~line 1667 add <xsl:template match="ead:origination | ead:scopecontent | ead:materialspec
        | ead:physloc | ead:container | ead:note | ead:userestrict" mode="itemDsc">...

I'm not able to test on our local AtoM server at this time, but I will let you know if I have any luck. Our public site is hosted by Artefactual, so we would have to wait for a future update or sponsor the change.


You received this message because you are subscribed to a topic in the Google Groups "AtoM Users" group.
To unsubscribe from this topic, visit
To unsubscribe from this group and all its topics, send an email to
To view this discussion on the web visit
Reply all
Reply to author
0 new messages