Document the OAR "item-release" script procedures

[jrgriffiniii]

These are found within the oar/item-release directory for https://github.com/PrincetonUniversityLibrary/dspace-operations/tree/master/oar/item-release, wherein which are the scripts for synchronizing items from Elements into the OAR DSpace implementation.

[jrgriffiniii]

For the e-mail functionality for item "releases" from Symplectic Elements, one finds two scripts. This is within the directory /u/dspace/oar/item-release for the oar.princeton.edu server:

• oarArchive
• oarMailer

oarArchive first prints to the STDOUT the ARK server configuration (please see https://n2t.net/e/ark_ids.html) for the DSpace implementation. It then executes a Java procedure for "archiving" all unreleased items published under the symplectic user.

Then, the following procedures are invoked for DSpace:

• itemcounter (this is used to update the number of items in the repository - it synchronizes PostgreSQL with Solr
• generate-sitemaps (this updates the Sitemaps for the structure of the collection with new items)
• filter-media (this generates derivatives [PDFs from Word Documents, thumbnails, OCR text] from bitstreams/files)

oarArchive is not specific to any given faculty member, researcher, or department. All of the requests received by James for item releases for Symplectic Elements publications have been either departmental or specific to a faculty member.

oarMailer is a scripted procedure which uses a Java API extension in order to issue an e-mail to the faculty member for whom item(s) were just published from Symplectic. Because modifying this involves testing the Java code base and introducing more conditional logic for handling cases where each department has a different liaison e-mail address and e-mail text body, attempts to extend this were never undertaken.

[jrgriffiniii]

By contrast, there were two scripts which I've seen actively used for releasing items from Symplectic:

• quickArchiveAuthors
• quickArchiveDepartment

Both of these invoke the edu.princeton.oar.Archive Java API extension, however, with the additional argument archive_without_email. This is what began to cease the e-mail notifications to faculty. Also, the argument --select pu.author.department --value "[DEPARTMENT_NAME]" were passed for selecting the subset of items synchronized from Elements to be released for public access.

[jrgriffiniii]

Please be aware that the Java API extensions for these procedures can be found in https://github.com/PrincetonUniversityLibrary/dspace-api-pu/blob/master/src/main/java/edu/princeton/oar/Archive.java and https://github.com/PrincetonUniversityLibrary/dspace-api-pu/blob/master/src/main/java/edu/princeton/oar/Mailer.java

[jrgriffiniii]

https://github.com/PrincetonUniversityLibrary/dspace-api-pu/blob/master/src/main/java/edu/princeton/cli/Arguments.java provides the base Java Class for CLI commands which are run for the OAR item import/synchronization tasks.

[jrgriffiniii]

https://github.com/PrincetonUniversityLibrary/dspace-api-pu/blob/master/src/main/java/edu/princeton/oar/Archive.java#L98 is the pattern in which CLI command Classes in Java are providing their own Classes for parsing command-line arguments.

[jrgriffiniii]

Archive does have the ability to release only a subset of items using a query against item descriptive metadata. Archive#doit is the method used as the access-point for actually executing the CLI task. Items are released exclusively by modifying the WorkflowItem object associated with the DSpace Item object, and moving it to the workflow step 3.

[jrgriffiniii]

For Mailer, #doit is invoked once again: https://github.com/PrincetonUniversityLibrary/dspace-api-pu/blob/master/src/main/java/edu/princeton/oar/Mailer.java#L332, but a template filename is provided as an argument. Beyond this in the code base, https://github.com/DSpace/DSpace/blob/dspace-5.3/dspace-api/src/main/java/org/dspace/core/Email.java#L237 is the inspiration for the approach which is used to send the e-mail to the user (using javax.mail.Transport as package for interfacing with the SMTP server).

[jrgriffiniii]

/dspace/config/dspace.cfg contains an entry mail.from.address, and I suspect that this might be where the "from" field for the OAR mailing service is provided. If this is indeed the case, then this not permit one to provide an alternative "from" field without modifying the Java code base for the mailing service.

[jrgriffiniii]

James will try and use Maven to build the packages for a new WAR, and reimplement a Java API extension to test with an alternative implementation.

[jrgriffiniii]

Issue moved to pulibrary/dspace-development #232 via ZenHub