Create SCCS workflow

[jonavellecuerdo]

Purpose and background context

This PR creates the SCCS DSC workflow. Implementation of the SCCS workflow was amazingly simple as it inherits from the SimpleCSV base workflow and only required assigning values for the workflow_name and metadata_mapping_path class attributes. This also introduces a new folder in dsc/workflows to hold metadata mapping JSON files.

• demo.json (formerly demo_metadata_mapping.json) was moved from the tests/fixtures folder.
• sccs.json is an updated version of the metadata mapping JSON file from dspace-api-python-scripts

This PR also includes additional changes for cleanup:

• Renaming DemoWorkflow -> Demo
• Changing email_recipients to list[str]
  Note: @ehanson8 , mypy may have been throwing an error previously if it was assigned an empty list ([]) (a "mutable default") in the __init__ signature. 🤔
• Cleaning up TestWorkflow and TestSimpleCSV fixtures
  • Pass values for email_recipients and output_queue when creating instances (i.e., base_workflow_instance and simple_csv_workflow_instance fixtures)

How can a reviewer manually see the effects of these changes?

Run make lint and make test and verify all unit tests are passing.

@ehanson8 and I synced up to discuss testing and whether new unit tests were required for the creation of the SCCS workflow. In summary:

• A test_<workflow>.py module should only be created to test functionality of overridden methods.
• Metadata mapping is covered by these unit tests. Regarding metadata mapping, these tests confirm:
  • Source field names -> Dublin Core field mappings is successful
  • Presence of delimiters results in entries created for each value in a delimiter-separated string
  • An error is raised when a field with "required": true is missing.

Includes new or updated dependencies?

NO

Changes expectations for external applications?

NO

What are the relevant tickets?

• https://mitlibraries.atlassian.net/browse/IN-1098

Developer

• All new ENV is documented in README
• All new ENV has been added to staging and production environments
• All related Jira tickets are linked in commit message(s)
• Stakeholder approval has been confirmed (or is not needed)

Code Reviewer(s)

• The commit message is clear and follows our guidelines (not just this PR message)
• There are appropriate tests covering any new functionality
• The provided documentation is sufficient for understanding any new functionality introduced
• Any manual tests have been performed or provided examples verified
• New dependencies are appropriate or there were no changes

[ehanson8]

Looks great and the organizational changes are excellent!

[ehanson8]

If the linting is passing then I guess this is all good!

[ghukill]

Left a couple of comments and questions, but approved regardless of answers!

[ghukill]

When looking at a class this minimal, a couple of thoughts come to mind:

1. Nice work on class design and inheritance! Clearly much is shared between workflows.
2. What functionality / opinionation, if anything, could this workflow-specific class still provide?

For # 2, the first thing that comes to mind is validation or hooks of some kind. I don't think it's necessary now, but wondering if there might be room in the future for some kind of registration of validation hooks, that could be used to validate items created? reconciliation logic? maybe others? In theory, these could be called -- if defined -- during the normal flow of the base Workflows.

Sketch:

class MyWorkflow(SimpleCSV):
    
    workflow_name = "Mine!"
    metadata_mapping_path = "path/to/mapping.json"
    
    # defined as class attributes, lists pointing to methods
    reconciliation_hooks = [] # I don't have any reconciliation hooks...
    item_creation_hooks = [
        "confirm_title_elements" # reference to method defined on class
    ]
    
    @classmethod
    def confirm_title_elements(cls):
        # I will check things yielded by Workflow.item_submissions_iter()...
        pass

With a little bit of wiring, this might provide a way for a Workflow class to have some additional validation (or even functional) logic applied to the base flows.

This pattern could also probably be achieved through decorators, which could be even cleaner.

Sketch:

class MyWorkflow(SimpleCSV):
    
    workflow_name = "Mine!"
    metadata_mapping_path = "path/to/mapping.json"
    
    @item_creation_hook
    def confirm_title_elements(cls):
        # I will check things yielded by Workflow.item_submissions_iter()...
        pass
   
    # maybe others like @reconciliation_hook

[coveralls]

Pull Request Test Coverage Report for Build 12797479564

Details

• 11 of 11 (100.0%) changed or added relevant lines in 4 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.03%) to 97.176%

---

Totals
Change from base Build 12774012547:	0.03%
Covered Lines:	413
Relevant Lines:	425

---

💛 - Coveralls