ngeraci / ucr_archivestools Goto Github PK

update readme in branch 0.2 with info on installing w/ setup.py, and new options and behaviors

oac_process currently ignores DAOs - this is important functionality to add

look at cdl code for example

how to set up Python environment, breaking down steps, etc.

See https://github.com/ucldc/nuxeo_spreadsheet/wiki for a useful example

Bug report from Andrew via email, 2020-02-19:

"I am working on the Patent Model finding aid (adding the images) and got the included set of errors. I am including the xml file that ASpace spit out. Since things are in flux I figured it was best to just send this straight to you for a quick look.

I checked validation in Oxygen and it didn’t like the “xlink:audience=” portion so I removed those and it still didn’t make it through the script. I compared with another published finding aid with DAOs (WRCA 039 Galloway papers) and it did not use either the audience or “xlink:role=” tag."

WRCA.110_20200219_204354_UTC__ead.txt

Due to non-standardization of WRCA collection numbers and filenames, names for WRCA files that have been processed with oac_process may not match existing filename for that collection.

(find example)

Issue reported by Jessica via email 2020-06-01:

I just started working on the UA collections, to update their top containers and conform them to the style guide, and I’m running into an issue with the oac-process script. For UA 001 I had no problem, but for UA 002 and UA 003 once they’ve been processed they’re being placed into the WRCA EAD folder, and have capital letters in the file name rather than the lowercase.

Issue appears to originate with EAD ID field in ArchivesSpace. Collections with issues have capitalized letters in EAD ID (such as UA002.xml instead of expected ua002.xml).

1. The filename for the EAD file is taken exactly from the "EAD ID" field in ASpace.
   * UA 002 and UA 003 have the "UA" capitalized in "EAD ID" which is why the filenames are coming out capitalized
2. The script is currently written to put files in the WRCA folder if "EAD ID" does not start with lowercase "ms" or "ua"

Desired behavior: filename is lowercase even if EAD ID is capitalized

Filename handling happens in https://github.com/ngeraci/ucr_archivestools/blob/2eab4caa26075521ef0bf7adbcc1c83af34865fe/aspace_tools/oac_process.py#L234:L265

Rather than process in-place in the Downloads folder, put processed file in standard location on shared drive.

potential issues:

• what behavior do we want for overwriting existing files? (prompt?)
• handling WRCA filenames

Bug report from Jessica via email:

I’m trying to publish the EAD for MS 051, the Biblioteca del Niño Mexicano facsimilies collection, and I’m having an error with the script. I downloaded the new updates, and they worked fine last week so I’m not sure if there’s something I need to fix in the ASpace record or not. Here’s what the error message is:

$ oac-process "C:\Users\jgeiser\Downloads\MS.051_20200224_212724_UTC__ead.xml"
Traceback (most recent call last):
  File "C:\Users\jgeiser\AppData\Local\Continuum\miniconda3\Scripts\oac-process-script.py", line 11, in <module>
    load_entry_point('aspace-tools==0.3', 'console_scripts', 'oac-process')()
  File "C:\Users\jgeiser\AppData\Local\Continuum\miniconda3\lib\site-packages\aspace_tools-0.3-py3.6.egg\aspace_tools\oac_process.py", line 69, in main
    finding_aid.process()
  File "C:\Users\jgeiser\AppData\Local\Continuum\miniconda3\lib\site-packages\aspace_tools-0.3-py3.6.egg\aspace_tools\oac_process.py", line 204, in process
    lxml_operations(self)
  File "C:\Users\jgeiser\AppData\Local\Continuum\miniconda3\lib\site-packages\aspace_tools-0.3-py3.6.egg\aspace_tools\oac_process.py", line 133, in lxml_operations
    titleproper.text = titleproper.text.strip()
AttributeError: 'NoneType' object has no attribute 'strip'

• figure out what kind of automated tests make sense and write them
• possibly implement Travis?

syntax error when reading EAD input file currently throws error "Not an EAD file." however, this doesn't cover all cases of this error & has led to user confusion (reported via email 6/14/18).

a perhaps more common case is that there's a markup error (like a broken user-inputted tag) making the XML not valid.