[Archivesspace_Users_Group] Containers not being associated with their resources

Mark Cyzyk mcyzyk at jhu.edu
Thu Mar 4 15:01:49 EST 2021


Still more:

I have attached three images.

1. Showing our Peabody Repository as having 0 Resources
2. Showing a test Resource we manually created in that repository (a 
image 1 above really should at least be reporting "1")
3. The output of the Resources List Report for the Peabody repository 
showing 140+ Resources

Reindexing does nothing to reconnect these Resources in the missing 
places to their Repository.

Is there some kind of database maintenance utility I can run to make 
this reconnect happen?

Worried,

Mark

<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
Mark Cyzyk, M.A., M.L.S.
Library Applications Group
The Sheridan Libraries
The Johns Hopkins University
mcyzyk at jhu.edu

Verba volant, scripta manent.

On 3/3/21 4:29 PM, Mark Cyzyk wrote:
>
> More:
>
> I turned back on the DB logging, forced the same error, and here is 
> part of what I captured:
>
>     I, [2021-03-03T12:31:02.401423 #29270]  INFO -- : (0.023387s)
>     SELECT * FROM `note` WHERE (`lang_material_id` IN (1058))
>     I, [2021-03-03T12:31:02.406634 #29270]  INFO -- : (0.005770s)
>     SELECT 1 AS `one` FROM `archival_object` INNER JOIN
>     `enumeration_value` AS `level_enum` ON (`level_enum`.`id` =
>     `archival_object`.`level_id`) WHERE ((`archival_object`.`id` !=
>     `archival_object`.`id`) AND (`archival_object`.`component_id` IS
>     NOT NULL) AND ((`level_enum`.`value` IN ('series')) OR
>     ((`level_enum`.`value` = 'otherlevel') AND (lower(`other_level`)
>     IN ('accession'))))) LIMIT 1
>     I, [2021-03-03T12:31:02.407401 #29270]  INFO -- : (0.007306s)
>     SELECT * FROM `instance_do_link_rlshp` WHERE (`instance_id` IN
>     (238583))
>     I, [2021-03-03T12:31:02.409280 #29270]  INFO -- : (0.005184s)
>     SELECT * FROM `note` WHERE (`lang_material_id` IN (1059, 2127))
>     I, [2021-03-03T12:31:02.409613 #29270]  INFO -- : (0.002386s)
>     SELECT * FROM `top_container_link_rlshp` WHERE (`top_container_id`
>     = 9074)
>     I, [2021-03-03T12:31:02.410056 #29270]  INFO -- : (0.000203s)
>     SELECT * FROM `subnote_metadata` WHERE (`note_id` IN (205950))
>     I, [2021-03-03T12:31:02.410913 #29270]  INFO -- : (0.012668s)
>     SELECT * FROM `note` WHERE (`lang_material_id` IN (1140, 2095))
>     RecordNotFound: /repositories/4/resources/1260
>
>
> Working my way up from the error, this query is returning 0 rows:
>
>      SELECT * FROM `instance_do_link_rlshp` WHERE (`instance_id` IN
>     (238583))
>
>
>
> <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
> Mark Cyzyk, M.A., M.L.S.
> Library Applications Group
> The Sheridan Libraries
> The Johns Hopkins University
> mcyzyk at jhu.edu
>
> Verba volant, scripta manent.
> On 3/3/21 10:54 AM, Mark Cyzyk wrote:
>>
>> Thanks!
>>
>> No FATAL or ERROR now.  But there is this:
>>
>>         INFO: [collection1] webapp= path=/select
>>         params={df=fullrecord&csv.escape=\&start=0&fq=-exclude_by_default:true&fq=publish:true&fq=types:pui&rows=1&bq=primary_type:resource^100+primary_type:accession^100+primary_type:subject^50+primary_type:agent_person^50+primary_type:agent_corporate_entity^30+primary_type:agent_family^30+&q=(uri:("\/repositories\/4\/resources\/1260"))&qf=title^25+four_part_id^50+fullrecord&pf=four_part_id^50&csv.header=true&csv.encapsulator="&wt=json&facet=true}
>>         hits=0 status=0 QTime=1
>>         RecordNotFound: /repositories/4/resources/1260
>>
>> <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
>> Mark Cyzyk, M.A., M.L.S.
>> Library Applications Group
>> The Sheridan Libraries
>> The Johns Hopkins University
>> mcyzyk at jhu.edu
>>
>> Verba volant, scripta manent.
>> On 3/3/21 10:30 AM, Blake Carver wrote:
>>> Those MySQL errors look like the ones already reported and are 
>>> probably not causing any problems.
>>>
>>> https://archivesspace.atlassian.net/browse/ANW-811?atlOrigin=eyJpIjoiMWJlMDQ4MzJlNjNiNDM0MWFlYzlhNDE5OGQ3NzIzYTYiLCJwIjoiaiJ9 
>>> <https://archivesspace.atlassian.net/browse/ANW-811?atlOrigin=eyJpIjoiMWJlMDQ4MzJlNjNiNDM0MWFlYzlhNDE5OGQ3NzIzYTYiLCJwIjoiaiJ9>
>>>
>>> Turn the mysql error logging thing off and set the other loglevel 
>>> errors to debug and look for any FATAL or ERROR in the logs.
>>> ------------------------------------------------------------------------
>>> *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org 
>>> <archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf 
>>> of Mark Cyzyk <mcyzyk at jhu.edu>
>>> *Sent:* Wednesday, March 3, 2021 10:20 AM
>>> *To:* Rachel Aileen Searcy <rachel.searcy at nyu.edu>; Archivesspace 
>>> Users Group <archivesspace_users_group at lyralists.lyrasis.org>
>>> *Subject:* Re: [Archivesspace_Users_Group] Containers not being 
>>> associated with their resources
>>>
>>> More:
>>>
>>> In our development environment, I configured full error logging.  I 
>>> then ran one of our queries that is failing, stopped ASpace, then 
>>> began scrutiny of archivesspace.out.
>>>
>>> Here are my disturbing findings:
>>>
>>>         E, [2021-03-03T09:47:29.950934 #27625] ERROR -- :
>>>         Java::ComMysqlJdbcExceptionsJdbc4::MySQLSyntaxErrorException:
>>>         Table
>>>         'archivesspaceDevelopment.agent_relationship_associative'
>>>         doesn't exist: DESCRIBE `agent_relationship_associative`
>>>         E, [2021-03-03T09:47:29.960346 #27625] ERROR -- :
>>>         Java::ComMysqlJdbcExceptionsJdbc4::MySQLSyntaxErrorException:
>>>         Table
>>>         'archivesspaceDevelopment.agent_relationship_associative'
>>>         doesn't exist: SELECT * FROM
>>>         `agent_relationship_associative` LIMIT 1
>>>         E, [2021-03-03T09:47:29.968749 #27625] ERROR -- :
>>>         Java::ComMysqlJdbcExceptionsJdbc4::MySQLSyntaxErrorException:
>>>         Table
>>>         'archivesspaceDevelopment.agent_relationship_associative'
>>>         doesn't exist: SELECT * FROM
>>>         `agent_relationship_associative` LIMIT 1
>>>         E, [2021-03-03T09:47:29.984480 #27625] ERROR -- :
>>>         Java::ComMysqlJdbcExceptionsJdbc4::MySQLSyntaxErrorException:
>>>         Table
>>>         'archivesspaceDevelopment.agent_relationship_earlierlater'
>>>         doesn't exist: DESCRIBE `agent_relationship_earlierlater`
>>>         E, [2021-03-03T09:47:29.987451 #27625] ERROR -- :
>>>         Java::ComMysqlJdbcExceptionsJdbc4::MySQLSyntaxErrorException:
>>>         Table
>>>         'archivesspaceDevelopment.agent_relationship_earlierlater'
>>>         doesn't exist: SELECT * FROM
>>>         `agent_relationship_earlierlater` LIMIT 1
>>>         E, [2021-03-03T09:47:29.990034 #27625] ERROR -- :
>>>         Java::ComMysqlJdbcExceptionsJdbc4::MySQLSyntaxErrorException:
>>>         Table
>>>         'archivesspaceDevelopment.agent_relationship_earlierlater'
>>>         doesn't exist: SELECT * FROM
>>>         `agent_relationship_earlierlater` LIMIT 1
>>>         E, [2021-03-03T09:47:30.000084 #27625] ERROR -- :
>>>         Java::ComMysqlJdbcExceptionsJdbc4::MySQLSyntaxErrorException:
>>>         Table
>>>         'archivesspaceDevelopment.agent_relationship_parentchild'
>>>         doesn't exist: DESCRIBE `agent_relationship_parentchild`
>>>         E, [2021-03-03T09:47:30.007362 #27625] ERROR -- :
>>>         Java::ComMysqlJdbcExceptionsJdbc4::MySQLSyntaxErrorException:
>>>         Table
>>>         'archivesspaceDevelopment.agent_relationship_parentchild'
>>>         doesn't exist: SELECT * FROM
>>>         `agent_relationship_parentchild` LIMIT 1
>>>         E, [2021-03-03T09:47:30.011525 #27625] ERROR -- :
>>>         Java::ComMysqlJdbcExceptionsJdbc4::MySQLSyntaxErrorException:
>>>         Table
>>>         'archivesspaceDevelopment.agent_relationship_parentchild'
>>>         doesn't exist: SELECT * FROM
>>>         `agent_relationship_parentchild` LIMIT 1
>>>         E, [2021-03-03T09:47:30.021769 #27625] ERROR -- :
>>>         Java::ComMysqlJdbcExceptionsJdbc4::MySQLSyntaxErrorException:
>>>         Table
>>>         'archivesspaceDevelopment.agent_relationship_subordinatesuperior'
>>>         doesn't exist: DESCRIBE `agent_relationship_subordinatesuperior`
>>>         E, [2021-03-03T09:47:30.024655 #27625] ERROR -- :
>>>         Java::ComMysqlJdbcExceptionsJdbc4::MySQLSyntaxErrorException:
>>>         Table
>>>         'archivesspaceDevelopment.agent_relationship_subordinatesuperior'
>>>         doesn't exist: SELECT * FROM
>>>         `agent_relationship_subordinatesuperior` LIMIT 1
>>>         E, [2021-03-03T09:47:30.028291 #27625] ERROR -- :
>>>         Java::ComMysqlJdbcExceptionsJdbc4::MySQLSyntaxErrorException:
>>>         Table
>>>         'archivesspaceDevelopment.agent_relationship_subordinatesuperior'
>>>         doesn't exist: SELECT * FROM
>>>         `agent_relationship_subordinatesuperior` LIMIT 1
>>>
>>>
>>>
>>>         E, [2021-03-03T09:47:30.166299 #27625] ERROR -- :
>>>         Java::ComMysqlJdbcExceptionsJdbc4::MySQLSyntaxErrorException:
>>>         Table 'archivesspaceDevelopment.container_location' doesn't
>>>         exist: DESCRIBE `container_location`
>>>         E, [2021-03-03T09:47:30.179378 #27625] ERROR -- :
>>>         Java::ComMysqlJdbcExceptionsJdbc4::MySQLSyntaxErrorException:
>>>         Table 'archivesspaceDevelopment.container_location' doesn't
>>>         exist: SELECT * FROM `container_location` LIMIT 1
>>>         E, [2021-03-03T09:47:30.181948 #27625] ERROR -- :
>>>         Java::ComMysqlJdbcExceptionsJdbc4::MySQLSyntaxErrorException:
>>>         Table 'archivesspaceDevelopment.container_location' doesn't
>>>         exist: SELECT * FROM `container_location` LIMIT 1
>>>
>>>
>>>
>>>         E, [2021-03-03T09:47:30.575599 #27625] ERROR -- :
>>>         Java::ComMysqlJdbcExceptionsJdbc4::MySQLSyntaxErrorException:
>>>         Table 'archivesspaceDevelopment.note_bibliography' doesn't
>>>         exist: DESCRIBE `note_bibliography`
>>>         E, [2021-03-03T09:47:30.579327 #27625] ERROR -- :
>>>         Java::ComMysqlJdbcExceptionsJdbc4::MySQLSyntaxErrorException:
>>>         Table 'archivesspaceDevelopment.note_bibliography' doesn't
>>>         exist: SELECT * FROM `note_bibliography` LIMIT 1
>>>         E, [2021-03-03T09:47:30.606147 #27625] ERROR -- :
>>>         Java::ComMysqlJdbcExceptionsJdbc4::MySQLSyntaxErrorException:
>>>         Table 'archivesspaceDevelopment.note_bibliography' doesn't
>>>         exist: SELECT * FROM `note_bibliography` LIMIT 1
>>>         E, [2021-03-03T09:47:30.635130 #27625] ERROR -- :
>>>         Java::ComMysqlJdbcExceptionsJdbc4::MySQLSyntaxErrorException:
>>>         Table 'archivesspaceDevelopment.note_digital_object' doesn't
>>>         exist: DESCRIBE `note_digital_object`
>>>         E, [2021-03-03T09:47:30.638129 #27625] ERROR -- :
>>>         Java::ComMysqlJdbcExceptionsJdbc4::MySQLSyntaxErrorException:
>>>         Table 'archivesspaceDevelopment.note_digital_object' doesn't
>>>         exist: SELECT * FROM `note_digital_object` LIMIT 1
>>>         E, [2021-03-03T09:47:30.645140 #27625] ERROR -- :
>>>         Java::ComMysqlJdbcExceptionsJdbc4::MySQLSyntaxErrorException:
>>>         Table 'archivesspaceDevelopment.note_digital_object' doesn't
>>>         exist: SELECT * FROM `note_digital_object` LIMIT 1
>>>         E, [2021-03-03T09:47:30.651197 #27625] ERROR -- :
>>>         Java::ComMysqlJdbcExceptionsJdbc4::MySQLSyntaxErrorException:
>>>         Table 'archivesspaceDevelopment.note_index' doesn't exist:
>>>         DESCRIBE `note_index`E, [2021-03-03T09:47:29.960346 #27625]
>>>         ERROR -- :
>>>         Java::ComMysqlJdbcExceptionsJdbc4::MySQLSyntaxErrorException:
>>>         Table
>>>         'archivesspaceDevelopment.agent_relationship_associative'
>>>         doesn't exist: SELECT * FROM
>>>         `agent_relationship_associative` LIMIT 1
>>>
>>>
>>>
>>> I took a look directly in the database and these tables are indeed 
>>> missing.
>>>
>>> At this point, I am stumped.  I don't understand why, with these 
>>> tables missing, one of our three Repositories would be working just 
>>> fine -- the other two, not so much.  How could whole tables get 
>>> deleted from our ASpace?  I'm guessing this happened a couple weeks ago.
>>>
>>> Any advice greatly appreciated,
>>>
>>> Mark
>>> <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
>>> Mark Cyzyk, M.A., M.L.S.
>>> Library Applications Group
>>> The Sheridan Libraries
>>> The Johns Hopkins University
>>> mcyzyk at jhu.edu  <mailto:mcyzyk at jhu.edu>
>>>
>>> Verba volant, scripta manent.
>>> On 3/1/21 5:18 PM, Mark Cyzyk wrote:
>>>>
>>>> Thanks, Rachel!
>>>>
>>>> I've now completely reindexed everything (a "hard reindex") and 
>>>> still no joy.
>>>>
>>>> I am noticing there is no "location.dat" file in our 
>>>> /indexer_pui_state/:
>>>>
>>>> -rw-r--r--. 1 archivesspace archivesspace   11 Mar  1 17:13 
>>>> 3_archival_object.dat
>>>> -rw-r--r--. 1 archivesspace archivesspace   11 Mar  1 17:13 
>>>> 3_classification.dat
>>>> -rw-r--r--. 1 archivesspace archivesspace   11 Mar  1 17:13 
>>>> 3_classification_term.dat
>>>> -rw-r--r--. 1 archivesspace archivesspace   11 Mar  1 17:13 
>>>> 3_digital_object_component.dat
>>>> -rw-r--r--. 1 archivesspace archivesspace   11 Mar  1 17:13 
>>>> 3_digital_object.dat
>>>> -rw-r--r--. 1 archivesspace archivesspace   11 Mar  1 17:13 
>>>> 3_resource.dat
>>>> -rw-r--r--. 1 archivesspace archivesspace   11 Mar  1 17:13 
>>>> 4_archival_object.dat
>>>> -rw-r--r--. 1 archivesspace archivesspace   11 Mar  1 17:13 
>>>> 4_classification.dat
>>>> -rw-r--r--. 1 archivesspace archivesspace   11 Mar  1 17:13 
>>>> 4_classification_term.dat
>>>> -rw-r--r--. 1 archivesspace archivesspace   11 Mar  1 17:13 
>>>> 4_digital_object_component.dat
>>>> -rw-r--r--. 1 archivesspace archivesspace   11 Mar  1 17:13 
>>>> 4_digital_object.dat
>>>> -rw-r--r--. 1 archivesspace archivesspace   11 Mar  1 17:13 
>>>> 4_resource.dat
>>>> -rw-r--r--. 1 archivesspace archivesspace   11 Mar  1 17:13 
>>>> 5_archival_object.dat
>>>> -rw-r--r--. 1 archivesspace archivesspace   11 Mar  1 17:13 
>>>> 5_classification.dat
>>>> -rw-r--r--. 1 archivesspace archivesspace   11 Mar  1 17:13 
>>>> 5_classification_term.dat
>>>> -rw-r--r--. 1 archivesspace archivesspace   11 Mar  1 17:13 
>>>> 5_digital_object_component.dat
>>>> -rw-r--r--. 1 archivesspace archivesspace   11 Mar  1 17:13 
>>>> 5_digital_object.dat
>>>> -rw-r--r--. 1 archivesspace archivesspace   11 Mar  1 17:13 
>>>> 5_resource.dat
>>>> -rw-r--r--. 1 archivesspace archivesspace   11 Mar  1 17:13 
>>>> _deletes_deletes.dat
>>>> -rw-r--r--. 1 archivesspace archivesspace   11 Mar  1 17:13 
>>>> repositories_repositories.dat
>>>>
>>>> Should there be?
>>>>
>>>> Our two problem repositories here are 4 and 5.  The Staff interface 
>>>> reports "0" Resources for both.  Yet when I run the Resources List 
>>>> Report I do indeed get back a report with Resources.  Puzzling.
>>>>
>>>> It's like something in the backend DB has become disconnected, but 
>>>> just for these two repositories.  Not sure how.
>>>>
>>>> If anyone has any suggestions, I would greatly appreciate hearing them!
>>>>
>>>> Mark
>>>>
>>>> <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
>>>> Mark Cyzyk, M.A., M.L.S.
>>>> Library Applications Group
>>>> The Sheridan Libraries
>>>> The Johns Hopkins University
>>>> mcyzyk at jhu.edu  <mailto:mcyzyk at jhu.edu>
>>>>
>>>> Verba volant, scripta manent.
>>>> On 2/24/21 11:11 AM, Rachel Aileen Searcy wrote:
>>>>> Hi Mark
>>>>>
>>>>> We ran into a similar issue recently, where newly created 
>>>>> containers were not being properly associated with the resource 
>>>>> record, and updates to locations or barcodes were not showing up 
>>>>> in searches or the Manage Top Containers view. We looked at the 
>>>>> timestamp files for the indexer, and noticed that there was no 
>>>>> location.dat file. We performed a soft re-index 
>>>>> <https://github.com/archivesspace/tech-docs/blob/master/administration/indexes.md>, 
>>>>> after which our containers, barcodes, and locations resumed 
>>>>> behaving as expected. We also have recurring monthly system 
>>>>> restarts (which will now include a soft re-index going forward) 
>>>>> built into our schedule, which seems to help with maintaining 
>>>>> overall performance.
>>>>>
>>>>> I'm not sure if this is exactly what you're experiencing, but I 
>>>>> hope it's helpful. Take care,
>>>>> Rachel
>>>>>
>>>>> On Mon, Feb 22, 2021 at 5:45 PM Mark Cyzyk <mcyzyk at jhu.edu 
>>>>> <mailto:mcyzyk at jhu.edu>> wrote:
>>>>>
>>>>>
>>>>>     Dear ASpace list,
>>>>>
>>>>>      From one of our Archivists:
>>>>>
>>>>>     > When I create a new container, either manually or by
>>>>>     spreadsheet
>>>>>     > ingest, the container appears properly in the Instance field
>>>>>     of the
>>>>>     > record. From the resource, I can open the container record
>>>>>     and it
>>>>>     > appears to be associated with the resource correctly.
>>>>>     However, in the
>>>>>     > container management module, when I search for all containers
>>>>>     > associated with the collection, the recently created
>>>>>     container is not
>>>>>     > listed. If I search for the new container's barcode, the
>>>>>     container
>>>>>     > appears in the search results but with no associated
>>>>>     resource. I can
>>>>>     > also locate the new containers by searching for unassociated
>>>>>     containers.
>>>>>
>>>>>     It seems like some linkage is not happening here.
>>>>>
>>>>>     More, this is only happening in his Repository, not our other,
>>>>>     larger
>>>>>     Repository.
>>>>>
>>>>>     Has anyone else run into this?
>>>>>
>>>>>     Mark
>>>>>
>>>>>     -- 
>>>>>     <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
>>>>>     Mark Cyzyk, M.A., M.L.S.
>>>>>     Library Applications Group
>>>>>     The Sheridan Libraries
>>>>>     The Johns Hopkins University
>>>>>     mcyzyk at jhu.edu <mailto:mcyzyk at jhu.edu>
>>>>>
>>>>>     Verba volant, scripta manent.
>>>>>
>>>>>     _______________________________________________
>>>>>     Archivesspace_Users_Group mailing list
>>>>>     Archivesspace_Users_Group at lyralists.lyrasis.org
>>>>>     <mailto:Archivesspace_Users_Group at lyralists.lyrasis.org>
>>>>>     https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup&d=DwICAg&c=slrrB7dE8n7gBJbeO0g-IQ&r=WwSkYr7X9POdZNK4180yTjrK5hSljcuCPIN--y1VRZk&m=SmteiGvtNVMomV11nXFZu2vgQ88h7aapUFt6H55qk9o&s=mbxfqYRQtAZn2xsehm9iyXz5ZA-q1Evo07_25hxNzk0&e=
>>>>>     <https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup&d=DwICAg&c=slrrB7dE8n7gBJbeO0g-IQ&r=WwSkYr7X9POdZNK4180yTjrK5hSljcuCPIN--y1VRZk&m=SmteiGvtNVMomV11nXFZu2vgQ88h7aapUFt6H55qk9o&s=mbxfqYRQtAZn2xsehm9iyXz5ZA-q1Evo07_25hxNzk0&e=>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -- 
>>>>> Rachel Searcy
>>>>> Accessioning Archivist, Archival Collections Management
>>>>> New York University Libraries
>>>>> 212.998.2539 | rachel.searcy at nyu.edu <mailto:rachel.searcy at nyu.edu>
>>>>> My pronouns are she/her/hers
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20210304/691a0d71/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: aspace1.png
Type: image/png
Size: 113098 bytes
Desc: not available
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20210304/691a0d71/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: aspace2.png
Type: image/png
Size: 141304 bytes
Desc: not available
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20210304/691a0d71/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: aspace3.png
Type: image/png
Size: 750306 bytes
Desc: not available
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20210304/691a0d71/attachment-0005.png>


More information about the Archivesspace_Users_Group mailing list