Improvements customisation submission sections

[Atmire-Kristof]

References

• Fixes #9486
• REST PR #9489

Description

This PR aims to add better customisability of additional submission steps, mainly adding steps that should inherit functionality from other existing steps.

Instructions for Reviewers

We've added an attribute to the type tag of submission-steps in item-submission.xml. This tag is labeled "extends" and can contain a string value that refers to the existing type of a step the new step should inherit from.

From here-on out, it's up to the developer to decide which parts need extending or overwriting, but this approach avoids having to re-write entire sections when most of the functionality is the same as another existing step.

Details on how to add and customise a step

On the REST side:

• Add a step-definition in item-submission.xml with extends attribute on type referring to an existing step to re-use functionality. e.g. <type extends="upload">custom-upload</type>
• Create a processing class for this step and configure it in the same step-definition. e.g. <processing-class>org.dspace.app.rest.submit.step.CustomUploadStep</processing-class>
• If extending from upload step: Add an entry to the map in uploadConfigurationService bean in access-conditions.xml with the key matching the ID of your new step. The value can refer to the uploadConfigurationDefault or a new one if desired. e.g. <entry key="custom-upload" value-ref="uploadConfigurationDefault" />
• Optionally, if custom validation is required, create a new class extending from AbstractValidation (or the validation of the step you're extending) and configure it as a bean in spring-dspace-addon-validation-services.xml. The name has to match your type. If no validation bean is configured for your step, but one exists for the step you're extending from, that one will be used instead.

On the Angular side:

• Add a new property to the SectionsType enum matching your custom step type
• Create a new component extending from SectionModelComponent and annotate it with @renderSectionFor(SectionsType.{your-custom-step-type})

Example

To make testing easier, I've created a separate branch starting from my PR, containing some custom code for a very basic example of a custom upload step that inherits all of the functionality of the existing upload step, to give you an idea on how and where everything's configured. Also added several comments explaining into more detail, in case something isn't clear yet.

• Angular example branch here
• REST example branch here

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 & specs/tests), or I have provided reasons as to why that's not possible.
• My PR passes ESLint validation using yarn lint
• My PR doesn't introduce circular dependencies (verified via yarn check-circ-deps)
• My PR includes TypeDoc comments for all new (or modified) public methods and classes. It also includes TypeDoc for large or complex private methods.
• My PR passes all specs/tests and includes new/updated specs or tests based on the Code Testing Guide.
• If my PR includes new libraries/dependencies (in package.json), I've made sure their licenses align with the DSpace BSD License based on the Licensing of Contributions documentation.
• If my PR includes new features or configurations, I've provided basic technical documentation in the PR itself.
• If my PR fixes an issue ticket, I've linked them together.

[Atmire-Kristof]

@atarix83 , your commit from a couple years back has been reverted here to allow metadata to be properly parsed from the section's data on specifically upload sections, otherwise you can't have any data on the upload section, other than "files", which limits customisability of these types of steps.

Now, my question is, what was the reason these checks were added in the first place, if you remember? Because I couldn't find the reason and reverting it doesn't seem to break any functionality of the upload step, both when uploads are mandatory or not.

[msutya]

We tried to test these changes, checked out the PR branches, brought over the changes from the example branches. One problem we had is that the renderSectionFor from sections-decorator.ts is marked as deprecated.
If we still want to use the deprecated function, we can still run the branches, but when trying to create a new item the item form does not load in at all. Because of this we couldn't properly test the feature.

[kanasznagyzoltan]

We tried to test these changes, checked out the PR branches, brought over the changes from the example branches. One problem we had is that the renderSectionFor from sections-decorator.ts is marked as deprecated. If we still want to use the deprecated function, we can still run the branches, but when trying to create a new item the item form does not load in at all. Because of this we couldn't properly test the feature.

@Atmire-Kristof Could you help us what can be wrong.
We have done the modifications in the frontend code (using example branch) and also in the item-submission.xml. After starting the corresponding frontend and backend branch the frontend and backend are running but the submission form drops a javascript error and gives a white picture.

[ybnd]

@msutya sorry for the huge delay, but I think the problem you're referring to is not related to this PR, but to #2750 (tracked in #2898)

A few of the "dynamic component decorators" were deprecated in favour of static maps, right now the solution is to define new entries here.