Enforce non-repeatable fields in submission forms

[Atmire-Kristof]

References

• Fixes Metadata import from external sources: Import allows multiple values for fields defined as non-repeatable in submission forms DSpace#10560
• Backend PR Enforce non-repeatable fields in submission forms DSpace#10679

Description

This PR aims to display error messages when a form is submitted containing multiple values for a non-repeatable field.

Instructions for Reviewers

Requires REST side of PR (DSpace/DSpace#10679) in order for non-repeatable field errors to display.

List of changes in this PR:

• Added CUSTOM_VALIDATORS, provided as DYNAMIC_VALIDATORS in the init-service.
  • This is a Map containing validation functions, checking for issues (currently just one, checking non-repeatable fields) and adding them to the response
  • The specific custom validators can then be applied to any control model. The non-repeatable validator is added to the DynamicRowArrayModel in field-parser.
• Additionally, section-form component had issues with re-rendering unnecessarily because it was detecting changes to fields not belonging to the current section (e.g. the first section would detect changes to abstract, which is part of the second section). Added a filter in inCurrentSubmissionScope(field: string) to exclude those fields.

Steps to reproduce:

• Set up a REST api where dc.contributor.author is not repeatable (found this the easiest way to test, as most publications from external sources contain multiple authors)
• Start a new submission through my-dspace and import from external source such as pubmed. Choose an item with multiple authors.
• Attempt to submit with multiple authors in the form
• At this point, the form should fail to submit and show an error message below all the authors mentioning it's not repeatable.

Checklist

• My PR is created against the main branch of code (unless it is a backport or is fixing an issue specific to an older branch).
• 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 npm run lint
• My PR doesn't introduce circular dependencies (verified via npm run 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.
• My PR aligns with Accessibility guidelines if it makes changes to the user interface.
• My PR uses i18n (internationalization) keys instead of hardcoded English text, to allow for translations.
• My PR includes details on how to test it. I've provided clear instructions to reviewers on how to successfully test this fix or feature.
• 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.

[ybnd]

@Atmire-Kristof @alexandrevryghem apparently this change causes a regression for #1671 / #2252

For submission fields without a <linked-metadata-field> the Relationship list under the field is no longer updated on select/delete. You can see this in the Person form Publication field or by unlinking the Publication form author field from dc.contributor.author.

Can you find a way to reconcile both cases?

[github-actions]

Hi @Atmire-Kristof,
Conflicts have been detected against the base branch.
Please resolve these conflicts as soon as you can. Thanks!

[atarix83]

@tdonohue @Atmire-Kristof

On DSpace-CRIS this functionality has been already implemented. The result is the following

On REST side the changes are the same, on Angular part they are slightly different
4Science@74855e9
4Science@6165efe

Could we consider a porting?

[MMilosz]

It looks like this PR can be closed, since this feature will be ported from CRIS in release 10, see: #5145

Pinging @tdonohue

[tdonohue]

Thanks @MMilosz for noting the overlap here with the existing DSpace-CRIS merger PR #5145. Closing this in favor of #5145 as the merger-related PRs take precedence.

@Atmire-Kristof : Thank you for your contribution to DSpace. If we find that this is not solved by #5145 (and associated PRs), then I'd welcome you to reopen this at a future time.