Bug #13251
CSV information object import's updating logic for digital objects doesn't work
| Status: | Verified | Start date: | 01/30/2020 | |
|---|---|---|---|---|
| Priority: | Medium | Due date: | ||
| Assignee: | - | % Done: | 0% | |
| Category: | Digital object | |||
| Target version: | Release 2.6.0 | |||
| 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 over 2 years 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 over 2 years ago
- Status changed from New to Code Review
#3 Updated by Mike Cantelon over 2 years 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.
#4 Updated by Dan Gillean almost 2 years ago
- Status changed from QA/Review to Verified
- Target version set to Release 2.6.0