Curation tasks using the scripts and processes functionality

[jonas-atmire]

References

Add references/links to any related tickets or PRs.

• Link to Scripts and processes REST Contract -> There is no explicit rest contract for the curation tasks implementation
• Link to Curation Tasks documentation

Description

This PR adds in the functionality of the curation tasks to the recently merged scripts and processes functionality.
Documentation on the curation task can be found above.

Instructions for Reviewers

List of changes in this PR:

• The curation tasks process has been moved to the scripts.xml config
• CurationCli has been made a DSpaceRunnable
• Configuration of the script can be found in CurationClientOptions
• At present, all curation tasks are admin only (Which is checked in the CurationScriptConfiguration)

Starting a curation task can be done by performing a POST request on the endpoint

/api/system/scripts/curate/processes

All parameter values should be provided in the body that has to use the multipart/form-data content type.
The simples of this is with a properties parameter, than contains JSON with the required options, ie the following properties will start the 'noop' curation task(-t) for the provided eperson(-e) and handle (-i)

  {
    "name": "-e",
    "value": "atmirenv@gmail.com"
  },
  {
    "name": "-t",
    "value":"noop"
  },
  {
    "name": "-i",
    "value":"123456789/8"
  }
]

When using the '-T' option, this allows the code to handle a text file containing a list of tasknames to be performed. (An example which is also used in the IT can be found here
Note:
CurationScriptIT at present does not yet contain the check to see if calling the 'noop' task actually ends up on (This IS logged in the dspace logs, but not explicitly returned as a particular status, apart from the scripts and processes returning the properties that have been sent to the endpoint, but that is not a marker to see if it has been executed or not)
We need to investigate to properly and cleanly mock the 'NoOpCurationTask' (In combination with the autowiring that is being done in the class), after which we can verify if the 'perform' method has been called correctly.

Checklist

This checklist provides a reminder of what we are going to look for when reviewing your PR. You need not complete this checklist prior to creating your PR (draft PRs are always welcome). If you are unsure about an item in the checklist, don't hesitate to ask. We're here to help!

• My PR is small in size (e.g. less than 1,000 lines of code, not including comments & integration tests). Exceptions may be made if previously agreed upon.
• My PR passes Checkstyle validation based on the Code Style Guide.
• My PR includes Javadoc for all new (or modified) public methods and classes. It also includes Javadoc for large or complex private methods.
• My PR passes all tests and includes new/updated Unit or Integration Tests based on the Code Testing Guide.
• If my PR includes new, third-party dependencies (in any pom.xml), I've made sure their licenses align with the DSpace BSD License based on the Licensing of Contributions documentation.
• If my PR modifies the REST API, I've linked to the REST Contract page (or open PR) related to this change.

[tdonohue]

@jonas-atmire : Overall, this code looks good. Just a minor request inline.

However, I will note this PR looks like it has the same security issue as the "metadata-import" script has... It should not allow specifying the --email param from the Admin UI. Instead, it should define that automatically to be the current user. See #2822

You may want to touch base with @KevinVdV on whether this issue needs to be resolved more generally. In general, no one should be allowed to bypass authorizations when running Scripts from the Admin UI. So, the --email param should be banned from the REST API & Admin UI for all scripts. If need be, we can solve this in a follow-up PR, but I'd like a clear plan for how we plan to resolve it prior to merging this PR.

I'm also surprised to see that the REST API is unable to return the results of the Curation Task. No matter which task I run, the results are only written to the log files, which makes this endpoint less useful -- you need commandline access anyhow to see the output, so why not just run it from commandline?

[tdonohue]

👍 Thanks @jonas-atmire . I've re-reviewed this and tested it with DSpace/dspace-angular#799 and everything is now working as expected.

As we previously discussed, the task output & security issues with the --eperson flag will be handled in separate PRs. So, this looks good to me as-is. Thanks again!

[tdonohue]

Merging this with one approval, as this backend has received several reviews from me & testing via the corresponding Angular PR from several individuals.