Bug #9753

AtoM 2.3 Accession CSV template not consistent with how columns used in 2.3 Information objects templates

Added by Dan Gillean about 6 years ago. Updated about 6 years ago.

Status:NewStart date:04/28/2016
Priority:MediumDue date:
Assignee:-% Done:


Category:CSV import
Target version:-
Google Code Legacy ID: Tested version:2.3
Sponsored:No Requires documentation:Yes


In the updated 2.3 accessions template, there is still a separate creators column - attaching here for reference. In the archival description csv templates, we managed to do away with this awkwardness - all events and actors, creation or otherwise, can be added to the same columns: eventActors, eventActorHistories, eventStartDates eventDates, eventTypes, eventEndDates, etc.

In the 2.3 accessions template it's a bit confusing:

  • creators must have the creator names (e.g. creator1|creator2)
  • eventActors must have NULL values (e.g. NULL|NULL)

Trying to add a 3rd actor, who is an accumulator, gets a bit weird. If you add a 3rd, piped, NULL value in the creators column this gets imported as a literal - you'll end up with a creator named NULL. So you would have to pipe all the other values, but NOT the creators column. Hardly intuitive.

Ideal workflow

  • creators column is removed - values are added to eventActors instead

I tried importing one like this, and my creators were not imported. Right now, AtoM is only looking for creators in the creators column. Other event types are less of a priority, since their creators will not display (as AtoM add other event actors as name access points, and there are no name access points on accession records - and they do not appear magically when an archival description is generated from an accession). Still, for clarity and consistency, I think we should use the same columns as we are now using the information_objects csv templates - and you should not need another column with NULL values for imports.

example_accessions.csv Magnifier - Current 2.3 Accessions csv template (1.03 KB) Dan Gillean, 04/28/2016 04:34 PM

example_accessions-ideal.csv Magnifier - IDEAL, post-fix CSV accessions template example to be added to code / used for testing (1.08 KB) Dan Gillean, 04/28/2016 04:59 PM

Related issues

Related to Access to Memory (AtoM) - Bug #9798: Accessions CSV: Donor Country does not import Verified 05/05/2016


#1 Updated by Dan Gillean about 6 years ago

Attaching what I think should be our updated 2.3 CSV accession template example, if this were fixed.

#2 Updated by Dan Gillean about 6 years ago

  • Status changed from New to Code Review

PR: https://github.com/artefactual/atom/pull/332

I sent the CSV example to Sara to test in her VM. Can you take a look at the changes and make sure all seems well, Mike? Got a funny message during my commit about line endings and want to make sure I haven't inadvertently made a mess of things. Thanks!

#3 Updated by Dan Gillean about 6 years ago

Note: this is really more of a workaround than a solution for this issue. If the PR is approved, I would still like to keep this issue open. I think we should still fix it - but in the meantime I've done what I can to remove unnecessarily confusing columns from the example.

#4 Updated by Dan Gillean about 6 years ago

  • Related to Bug #9798: Accessions CSV: Donor Country does not import added

#5 Updated by Mike Gale about 6 years ago

  • Status changed from Code Review to Verified

Tested locally, accessions from the new example .csv import correctly.

#6 Updated by Dan Gillean about 6 years ago

  • Status changed from Verified to New
  • Assignee deleted (Mike Gale)

Thanks! I am going to leave this ticket as new, because my PR does not actually solve the issue as identified in the description - it merely reduces end user confusion by removing confusing rows that are unnecessary for import. I still think we should harmonize how events/actors works with how it does for IOs, so there is consistency in the application.

Also available in: Atom PDF