Bug #13251

CSV information object import's updating logic for digital objects doesn't work

Added by Mike Cantelon 27 days ago. Updated 21 days ago.

Status:QA/ReviewStart date:01/30/2020
Priority:MediumDue date:
Assignee:-% Done:

0%

Category:Digital object
Target version:-
Google Code Legacy ID: Tested version:
Sponsored:No Requires documentation:

Description

In the CSV information object import code there's logic for updating digital objects that has an issue.

If you, during a CSV import in update mode, specify a new digital object path or URI the update logic needs to first delete the existing object before updating.

This logic is triggered In the lib/task/import/csvImportTask.class.php file (in the updatePreparationLogic closure). The method currently used to fetch the information object's current digital object, getDigitalObject, fetches a derivative digital object rather than the mail digital object. The reason for this is it treats the getDigitalObjectRelatedByobjectId result as an array of digital objects rather than a digital object.

History

#1 Updated by Mike Cantelon 22 days ago

How to replicate (using test script test_do.php... contents of script at: https://bit.ly/3b7y7jb).

Testing with old, working version (needs to be done on 16.04)

# From AtoM root directory
git checkout eef9c26b6aab2aab62bfdbf0aaac55169857a91d
php symfony cc
php symfony tools:purge --demo
php symfony csv:import lib/task/import/example/isad/example_information_objects_isad.csv

# Run script
php symfony tools:run test_do.php

Output of test_do.php (https://bit.ly/31oQH1Z):

$ ./symfony tools:run test_do.php 
Loaded I.O. ID (fonds with D.O.): 443
ID of D.O. returned from getDigitalObject() method: 466
Usage ID of D.O.: 166
Type returned from getDigitalObject() method: object
Class returned from getDigitalObject() method: QubitDigitalObject
(Class will show as 'runCustomLogicTask' if null.)

Loaded I.O. ID (item with no D.O.): 469
ID of D.O. returned from getDigitalObject() method: 
Usage ID of D.O.: 
Type returned from getDigitalObject() method: NULL
Class returned from getDigitalObject() method: runCustomLogicTask
(Class will show as 'runCustomLogicTask' if null.)
Done.

Testing with latest code, non-working version (needs to be done on Bionic)

# From AtoM root directory
git checkout qa/2.6.x
php symfony cc
php symfony tools:purge --demo
php symfony csv:import lib/task/import/example/isad/example_information_objects_isad.csv

# Run script
php symfony tools:run test_do.php

Output of test_do.php (https://bit.ly/2GNFONE):

$ ./symfony tools:run test_do.php 
Loaded I.O. ID (fonds with D.O.): 444
ID of D.O. returned from getDigitalObject() method: 469
Usage ID of D.O.: 142
Type returned from getDigitalObject() method: object
Class returned from getDigitalObject() method: QubitDigitalObject
(Class will show as 'runCustomLogicTask' if null.)

Loaded I.O. ID (item with no D.O.): 470
ID of D.O. returned from getDigitalObject() method: 
Usage ID of D.O.: 
Type returned from getDigitalObject() method: NULL
Class returned from getDigitalObject() method: 
(Class will show as 'runCustomLogicTask' if null.)
Done.

Conclusion

The different D.O. usage IDs indicate that different D.O.s are being returned.

The D.O. returned by the old, working, version is 166 (QubitTerm::EXTERNAL_URI_ID: expected) whereas the D.O. returned by the new version is 142 (QubitTerm::THUMBNAIL_ID: not expected).

#2 Updated by Mike Cantelon 22 days ago

  • Status changed from New to Code Review

#3 Updated by Mike Cantelon 21 days ago

  • Status changed from Code Review to QA/Review

Merged into qa/2.6.x.

Not sure if this needs to be QAed, but I guess someone could re-run the test script to prove the fix.

Also available in: Atom PDF