[5] Investigate impact of tickets related to the BulkOps Overhaul on Bulkrax

[bkiahstroud]

Summary

Investigate each sub-ticket of UCSCLibrary/dams_project_mgmt#436 to see if the issue(s) described by that ticket apply to Bulkrax. If any of them could potentially impact ingests using Bulkrax, note how.

Acceptance Criteria

• Investigate the following in relation to Bulkrax:
  • [x] UCSCLibrary/dams_project_mgmt#415
  • [x] UCSCLibrary/ucsc-library-digital-collections#383
  • [x] UCSCLibrary/dams_project_mgmt#378
  • [x] UCSCLibrary/dams_project_mgmt#252
  • [x] UCSCLibrary/dams_project_mgmt#186
  • [x] UCSCLibrary/dams_project_mgmt#164
• [x] Discuss necessary next steps based on the investigation results

[bkiahstroud]

For more detailed, official investigation results, see below

Initial thoughts at a glance:

- No logic exists in Bulkrax to order FileSets - Bulkrax has no equivalent to BulkOps’ “order” column - “Permission conflicts in shared derivative drive” - This will likely still be an issue when ingesting with Bulkrax - “Sometimes filesets are not fully attached to their works” - Should be investigated for Bulkrax - “Fix ingest of jpegs & compressed TIFFs” - Related to kakatu issues — still a problem for Bulkrax - “Add option to wipe existing metadata on bulk work update” - Feature does not exist in Bulkrax - Bulkrax does provide option to delete individual values from existing records upon import

[bkiahstroud]

Results

Summary

The following issues clearly still apply to Bulkrax:

• UCSCLibrary/dams_project_mgmt#378
• UCSCLibrary/dams_project_mgmt#186

Other issues may apply as well, but need to be discussed.

---

• UCSCLibrary/dams_project_mgmt#415
  • FileSets ingested through Bulkrax are named properly
  • Order of FileSets is not guaranteed when importing with Bulkrax
• UCSCLibrary/ucsc-library-digital-collections#383

  • Currently [in BulkOps], when ingesting complex objects, the order of child objects is specified by the order of their rows on the ingest spreadsheet

  • The order of child objects is not guaranteed to match the order of rows in the spreadsheet when importing using Bulkrax
  • This functionality appears to be currently broken in BulkOps according to UCSCLibrary/dams_project_mgmt#415
• UCSCLibrary/dams_project_mgmt#378
  • This is still a problem for Bulkrax ingests, since both BulkOps and Bulkrax depend on various shared resources between servers
  • This was fixed manually on the sandbox server by Kiah and Sneha, but will need to be fixed on staging and production when deployments go out to those servers
  • To ensure the problem does not continue occurring, a programmatic solution should be found and implemented
• UCSCLibrary/dams_project_mgmt#252
  • So far, does not appear to be an issue shared by Bulkrax
  • No failed FileSetAttachedEventJob have been observed during testing thus far
  • FileSets imported using Bulkrax have their #parent set correctly
• UCSCLibrary/dams_project_mgmt#186
  • Still an issue for ingests through Bulkrax
  • This is the "kakadu" issue
  • Currently being investigated by @snehagunduraoUL
  • Not directly related to ingests
  • Ingests work fine (metadata, associating records, etc), but images ingested (as well as images uploaded not via ingest) are not being processed properly
• UCSCLibrary/dams_project_mgmt#164
  • This was a request for a new feature in BulkOps
  • No feature equivalent to this one exists in Bulkrax
  • Bulkrax is capable of updating existing metadata on records
  • Bulkrax is capable of nulling out existing metadata on records on a property-by-property level
    • This is done by importing a header with an empty value