Bug #6755

CSV import: physicalObjectType values that do not conform to AtoM defaults cause import failure

Added by Dan Gillean almost 8 years ago. Updated almost 8 years ago.

Status:VerifiedStart date:05/26/2014
Priority:MediumDue date:
Assignee:Dan Gillean% Done:


Category:CSV import
Target version:Release 2.1.0
Google Code Legacy ID: Tested version:
Sponsored:No Requires documentation:


To reproduce

Case 1:
1) Using one of the AtoM archival description import templates, try entering dummy data into the field (e.g. "chocolate"). Save.
2) Try to import the CSV

Case 2:
1) Create a new term in the Physical object type taxonomy, called "chocolate", and save.
2) Repeat steps 1 and 2 from case 1 above.

Resulting error
CSV fails to import. Produces the following error message:

Unable to execute INSERT statement. [wrapped: SQLSTATE23000: Integrity constraint violation: 1452 Cannot add or update a child row: a foreign key constraint fails (`atom_2x`.`physical_object`, CONSTRAINT `physical_object_FK_2` FOREIGN KEY (`type_id`) REFERENCES `term` (`id`) ON DELETE SET NULL)]

Expected result
Generally AtoM should create a new term in the relevant taxonomy when encountering data that does not match any existing term. In fact, there is a function at work on this field called "createOrFetchPhysicalObject" whose very name seems to suggest that this is the intended behavior.

In both cases 1 and 2, the import should succeed. In case 1, a new term should be created in the taxonomy which can then be edited by the user if desired. In case 2, it should be linked to the new term "chocolate" created by the user via the GUI.


#1 Updated by Mike Gale almost 8 years ago


array_search is passing in a bool(false) to the method which is causing the error.

#2 Updated by Tim Hutchinson almost 8 years ago

The other field where I got an equivalent error was level of detail (under description control area - minimal|full|partial). As opposed to level of description.

And for description status, the import routine checks for valid values, and blanks invalid values, rather than adding the new value. (Final|revised|draft. As opposed to publication status.)

#3 Updated by Mike Gale almost 8 years ago

  • Status changed from New to QA/Review
  • Assignee changed from Mike Gale to Dan Gillean

I pushed a fix to 2.x Dan, it seemed to be fine from my tests. Cheers

#4 Updated by Mike Gale almost 8 years ago

Thanks for your input, Tim.

Dan, would you like to create other tickets for these other columns Tim mentioned, or re-open this ticket?

#5 Updated by Sarah Romkey almost 8 years ago

I would suggest that we open separate tickets and do a thorough test of each field which should be updating a taxonomy. I have been doing some tests while documenting our RAD template and noticed similar behavior.

#6 Updated by Sarah Romkey almost 8 years ago

  • Status changed from QA/Review to Verified

Verified in 2x, works as expected.

Also available in: Atom PDF