[DSpace-CRIS] Porting of authority framework functionalities (Frontend)

[FrancescoMolinaro]

References

• Fixes [DSpace-CRIS] Data model preparation work (Authority Framework enhancements, etc) DSpace#11748
• Requires backend PR: [DSpace-CRIS] Porting of authority framework functionalities (Backend) DSpace#11718
• Relates to: [DSpace-CRIS] Creation of a custom URL for Items (Frontend) #4814

Description

Initial port of the DSpace-CRIS authority framework into core DSpace, enabling real-time entity lookup, confidence-based linking, and automatic graph maintenance through server-side consumers.

On the UI this PR introduces a new way to link authorithy controlled metadata to the related item, generating a link in search results or item page, this connection is handled in submission. (for configuration check the rest PR)

Through a rest configuration, is possible also to activate an "auto-fill" functionality, that will populate the submission fields based on the selected value (value must be authority controlled).

Exaple of config in cris-authority-metadatagenerator.xml:

<bean class="org.dspace.content.authority.ItemSimpleAuthorityMetadataGenerator">
    <property name="authorityName" value="AuthorAuthority"/>
    <property name="keyId" value="person_identifier_orcid"/>
    <property name="useForDisplay" value="true"/>
    <property name="useAsData" value="true"/>
    <property name="schema" value="person"/>
    <property name="element" value="identifier"/>
    <property name="qualifier" value="orcid"/>
    <property name="singleResultOnAggregate" value="true"/>
</bean>

auto-fill.webm

The information of the related item are previewed via a new pop-up component enabled on hover, visible on both search results and item page:

In addition the PR introduce also multilanguage support for authority controlled vocabularies, to achieve this we need to have a vocabulary version for each language enabled by the property: webui.supported.locales

For instance if we have

webui.supported.locales = en, de

we can create a translated vocabulary (srsc_de in this example) and then configure the authority as follows (authority.cfg):

vocabulary.plugin.srsc.hierarchy.store = true
vocabulary.plugin.srsc.hierarchy.suggest = true
vocabulary.plugin.srsc.delimiter = "::"
vocabulary.plugin.authority.store = true
authority.controlled.dc.subject = true

This will enable to display the translated value in the UI, if the language matches the translated one:

EN:

DE:

This last feature will be consolidated later in the merger with the cust layout functionality from CRIS (at the moment this is not presente in the exact same way on CRIS as there we rely on the layout feature that is not yet in scope).
The implementation will remain anyway as it will be useful also as fallback for not configured layouts.

Instructions for Reviewers

Once the item relation is enstablished (submitted) the metadata will be linking to the related item, with a preview of metadata visible on link hover.

The new configuration for the pop-hover preview is available in default-app.config.ts, under the name:

metadataLinkViewPopoverData

It provides the opportunity to customize the preview metadata based on entity type.

In submission is possible also to configure specific icons for each source of authority, see config:

sourceIcons (under authority config)

In general for the newly added configuration you can refer to the config.example.yml file.

Once submitted, the authorithy controlled value should then result in a clickable link the search results (if the value is displayed) and in a clickable link in the item page (see images above).

Is possible to configure also auto-fill and generated metadata based on the authority (see descriptio or rest PR).

For the multilanguage support on vocabularies a translated vocabulary and submission form are needed, in addition to the properties based on the vocabulary name and metadata (see description).

List of changes in this PR:

Enhanced search results and item page with linkable related items (authority controlled)
Added new popover component for metadata preview on hover.
Implemented custom pipe for icon/info handling in onebox component.
Improved editing of authority via admin view, improved handling of search filters (filter by authorithy not value).
Implemented auto-fill functionality in submission.
Added support for multilanguage visualization of controlled vocabulary values in item page.

Checklist

This checklist provides a reminder of what we are going to look for when reviewing your PR. You do not need to complete this checklist prior creating your PR (draft PRs are always welcome).
However, reviewers may request that you complete any actions in this list if you have not done so. If you are unsure about an item in the checklist, don't hesitate to ask. We're here to help!

• 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.

[github-actions]

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

[artlowel]

Hi @FrancescoMolinaro

Apologies for the delayed response, I’ve been out sick.

It looks like #4814 has already been merged in the meantime.

Following the referenced PR, when the relevant metadata is present, the custom URL replaces the standard UUID/ID parameter in the page URL and effectively becomes a unique identifier for the item.

For this reason, we considered it preferable to keep the validation logic inside the findById method, as this approach minimizes the impact across the application and avoids the need to modify multiple code paths where the UUID/ID is extracted from the URL.

The reason for my original comment is that findById is used consistently throughout the application to retrieve resources by their UUID.

Handles are also unique identifiers for a resource, as are self links, and these are handled separately through dedicated methods and resolvers. While I understand that placing this logic inside findById may reduce the number of changes required, it introduces inconsistency across dataservices and increases the risk of edge cases.

In my view, this logic should be moved out of findById, either as part of this PR or in a separate, focused PR before the release of DSpace 10.

[MarieVerdonck]

Simple item page issues

• If multiple authors linked this way after each other, they show up next to each other on item page instead of underneath each other
  • Both if no linked item could be created (for example if there is no collection with Person entity) => The authors on simple item page, which still have will be generated::ORCID::{orcid} authority but confidence -1
  • And if link does happen

• Clicking on linked author => person page has search with search.filters.applied.f.isAuthorOfPublication: {person-uuid}
  • i18n message not resolved
  • This shows no results? Either indexing or filter name issue? => Expect at least Publication you just came from to show up, and all other publications this Person is linked to as author

[MarieVerdonck]

Submission UI improvements

• Once selected from dropdown in submission there is no visual indicator to distinguish plain text authors in the list from authority controlled authors added this way. So it's not clear to user whether the "authority" has been successfully select/applied, so it would be an improvement if an alternate way to render mdv in list with authority was applied.

[FrancescoMolinaro]

Hi @MarieVerdonck, thanks for the feedback, much appreciated.
Regarding the submission improvment to detect if the authority has been applied, I wanted to say that it will be ported as part of #5097 , the UI can be configured to display some chips as follows:

Here we will have icons with colors matching the confidence of the authority.

For the label in the search component in item page I believe is unrelated to this PR as the issue is present also on the demo instance, e.g.
https://demo.dspace.org/entities/person/bcf6b178-dcfb-4fbe-b21b-6e0a936b531c .
The missing search results I believe are a rest issue, not sure what in specific, but if I use the demo or the sandbox for the rest connection I can properly see results in the search.

Instead for the positioning of the authors in the item page I have pushed a fix to have the list stacked vertically as it was before.

Additional note:

In the regular form the authority feedback is given by the circle icon in the input, that will have a different color based on the confidence:

It would be really appreciated if you could check this again, many thanks.

[tdonohue]

@FrancescoMolinaro : Thanks for this PR! I gave this some testing today (alongside the backend PR). Mostly, it's working. However, there are some display issues in the User interface that I'm seeing:

1. When submitting a Publication, if I search up an author's name, I can choose someone from either local database or ORCID sandbox. However, the icons always show a database icon. In the screenshot below, these are all authors that only exist in the ORCID sandbox but there is no ORCID icon (like in your screenshot in the description of this PR).

2. The display of authors in search results is now messed up. Authors will not be displayed unless you click the "Show More" button. But, after clicking "Show More" you see the author names vertically like this screenshot:

3. If I create a Publication with three authors and then visit the publication page, the author hover-overs work well. However, it's very difficult to click the "More info" link in the hover-over for the second or third author. As soon as you move the mouse up, the popup for the author above appears. You have to carefully move the mouse in a diagonal to get to the link. This is a smaller thing, but it seems like a usability issue.

4. Finally, if you succeed in clicking "More Info" in the hover-over (see the third item just above), then that hover-over will "flash" briefly in the upper right corner of the page before loading the Person page for this Author. This is also minor, but I'm consistently seeing a "flash" anytime I click this "More infor" link.

I'm still testing & haven't done a code review here yet. But, that's what I've found so far.

[MarieVerdonck]

Regular author lookup issue

When reviewing this PR, I’m encountering a console error during author lookup (magnifying glass icon next to author lookup through which previously existing local or import-from-orcid entity Person items were linked) in the submission flow: NG0309: Directive NgbNavLinkBase matches multiple times on the same element. As a result, nothing is displayed in the lookup popup. From initial investigation, this appears to be related to an ng-bootstrap dependency/version issue. However, upgrading ng-bootstrap to resolve this leads to different build errors, so the situation is not straightforward.

Console message:

ERROR Error: NG0309: Directive NgbNavLinkBase matches multiple times on the same element. Directives can only match an element once.
    Angular 5
    DsDynamicLookupRelationModalComponent_Conditional_7_Template dynamic-lookup-relation-modal.component.html:13
    Angular 4
    DsDynamicLookupRelationModalComponent_Template dynamic-lookup-relation-modal.component.html:11
    Angular 21
    RxJS 6
    Angular 10
root_effect_scheduler.mjs:3637:23

Note I’m not certain this issue is introduced by this PR, but the problem does not occur on https://demo.dspace.org/. When building the current main branch locally, the sidebar does not render, and when trying to create a Publication item via /mydspace + button, the inputs in submission (Subscribe/Describe) do not render so can't check if issue already occurs there.

[tdonohue]

@FrancescoMolinaro : Thanks again for this PR! I've finished a code review and have some minor comments inline below. Most of the comments are requests for TypeDocs or small accessibility improvements.

However, I've also asked for some possible restructuring of the configuration (to group together related configs). While I'd rather do this restructuring now, we could potentially delay it if necessary. I just wanted to stress that we are trying to maintain some "order" / "hierarchy" in our config.yml, and this PR doesn't really obey those current best practices.

See inline comments below. Thanks again!

[FrancescoMolinaro]

Hi @tdonohue, many thanks for the review, much appreciated.
I have reorganized the configuration properties as you suggested and I realized that I have ported a configuration that was not in scope for this PR (AdditionalMetadataConfig) and that some of the added ones where not yet fully used, therefore I have removed what wasn't necessary and integrated what was missing.

Regarding the missing ORCID icon in submission, I think a config on the rest side was missing under authority.cfg:

cris.ItemAuthority.AuthorAuthority.source = orcid

Now it should be present also on the rest PR.
For the popover instead I made some improvments regarding the placement and the closing delay so that should be easier for the user to navigate them.

I have also fixed the search results layout so that the authors are visible as before and correctly placed:

In addition I have improved the closing method so to clear the HTML reference on navigation, so that the flash on the page corner won't happen.

[FrancescoMolinaro]

Hi @MarieVerdonck , thanks for the feedback, I just checked the issue and is indeed caused by the update we did for ng-bootstrap: #4898

I have fixed it in this PR but I have also open a separated issue that I will address asap, as this issue is unrelated from this PR: #5169

[tdonohue]

@FrancescoMolinaro : I gave this another test today (with the backend PR). The prior bugs that I found in my first test from last week have all been resolved! Thanks!

However, the code review feedback that I also gave last week (in a separate review) is mostly unresolved. For example, I'm not seeing any of the accessibility improvements I suggested. (It looks like only around the first 5 requests were fixed, while the other 20+ have mostly not been solved yet.)

In my testing today, most everything is looking must better. However, I've also found a new bug that is appearing in SSR logs. Here's what I'm seeing:

1. Start the frontend in production mode (npm run build:prod && npm run serve:ssr)
2. Watch the SSR logs where you ran "npm run serve:ssr")
3. Visit the homepage, and you'll see an immediate error in the SSR logs which looks like this:

ERROR ReferenceError: document is not defined
    at new StickyPopoverDirective2 (C:\dspace-angular\dist\server\main.js:1:1673632)
    at NodeInjectorFactory.ɵfac [as factory] (C:\dspace-angular\dist\server\main.js:1:1674926)
    at getNodeInjectable (C:\dspace-angular\dist\server\main.js:1:3915934)
    at instantiateAllDirectives (C:\dspace-angular\dist\server\main.js:1:3979403)
    at createDirectivesInstances (C:\dspace-angular\dist\server\main.js:1:3979712)
    at Object.ɵɵelementStart (C:\dspace-angular\dist\server\main.js:1:4131435)
    at MetadataLinkViewComponent_ng_template_2_Template (C:\dspace-angular\dist\server\main.js:1:1676800)
    at executeTemplate (C:\dspace-angular\dist\server\main.js:1:3978418)
    at renderView (C:\dspace-angular\dist\server\main.js:1:3985607)
    at createAndRenderEmbeddedLView (C:\dspace-angular\dist\server\main.js:1:3986989)

This SSR error appears to be referencing the MetadataLinkViewComponent which is newly added in this PR.

If you can find time to address my other prior feedback, I'd love to give this an updated review. As I'm sure you're aware, this is blocking several other merger PRs. I'd really like to see this PR (and the backend) merged soon to unblock everything else.

[FrancescoMolinaro]

Hi @tdonohue , thanks for the feedback and sorry if missed some of the comments, now I should have addressed all the remaining open points and the new issue with the SSR error.

The issue was related to the window object being accessed in SSR inside StickyPopoverDirective, therefore I have adapted the logic so that it won't execute any rendering logic if not in the browser.

I believe this should be ready for another review, thanks in advance for the help.

[tdonohue]

👍 Thank you @FrancescoMolinaro ! I retested & re-reviewed this today, and all the prior bugs that I've reported are fixed. I can also verify my feedback has all been addressed in this PR. (That said, there's still feedback on the backend PR that needs addressing before I'm +1 on that as well)

This looks good to me now! I'd encourage other testers/reviewers (like @MarieVerdonck , @artlowel and @nwoodward ) to provide updated feedback soon. I'd really like to see this PR (and the backend) move forward as quickly as plausible in order to unblock all the other DSpace-CRIS merger PRs that depend on them.

[artlowel]

Thanks @FrancescoMolinaro!

I tested this again today and it looks good. I did find another potential issue in the code

[artlowel]

It looks like FormModels are added using this.formId as the identifier…

[artlowel]

… and removed using this.sectionData.id as the identifier, which could be a memory leak.

I thought those IDs might be identical, but I tried logging them to the console, and I get something like this:

addFormModel 3_traditionalpagetwo
addFormModel 2_traditionalpageone
removeFormModel traditionalpageone
removeFormModel traditionalpagetwo

You'll probably want to use this.formId for the removal as well

[FrancescoMolinaro]

Hi @artlowel , thanks for the feedback and the catch, you are absolutely right.
I have changed the removal identifier so that the form will be correctly removed from the state, avoiding possible memory leaks.