[DSpace-CRIS] Port CMS edit and User Agreement edit from DSpace CRIS

[Dawnkai]

References

• Resolves [DSpace-CRIS] Edit Content Management System (CMS) features DSpace#11751

Description

Port CMS metadata editing and user agreement editing as part of CRIS merger.

Instructions for Reviewers

This PR ports two functionalities: CMS metadata editing, and User Agreement editing from DSpace CRIS. I prioritized moving code from CRIS to DSpace as is, without drastic changes in logic and functionality. However, I can see a few places for improvement.

List of changes in this PR:

• A new component called AdminEditCmsMetadata has been added. This view is responsible for editing metadata on the Site object, which will then be displayed in selected parts of DSpace.
• A new component called AdminEditUserAgreement has been added. This view is responsible for editing the user agreement metadata, which is displayed instead of the usual User Agreement text.
• Four components have been edited to support new metadata and will display it if it has been set through CMS edit or User Agreement edit: FooterComponent, HomeNewsComponent, HomePageComponent and EndUserAgreementContentComponent.
• New translation keys have been added to translation files along with the default English translation.
• New entries have been added in the Admin Panel sidebar - one for CMS metadata edit and the other for User Agreement content edit.
• When User Agreement is edited, administrators will have an option to reset the user agreement status using the metadata-deletion process on the backend. This means that all users will be forced to accept UA again.

In order to test this PR, you have to first import the metadata registry entries from DSpace/DSpace#11896.

CMS metadata edit

Then, when you log in as an admin, you should see two new buttons on the admin panel:

Then, you should be able to select three metadata values: cris.cms.home-header, cris.cms.home-news and cris.cms.footer. Select the value you wish to edit. I recommend selecting cris.cms.home-header, as that one will be visible right away. Then, type something in the textarea for the langauge of your choice:

And then click Save. After returning to the home page, you should see that text instead of the regular DSpace banner:

In order to test the other metadata, you will have to not only repeat the steps for those metadata, but also make some changes in the code:

• cris.cms.footer requires you to edit showTopFooter in FooterComponent to true.
• cris.cms.home-news requires you to remove the cris.cms.home-header metadata and then set cris.cms.home-news metadata. Or you can simply temporarily pull the ds-home-news component out of the @if statement in the home-page.component.html file.

User Agreement edit

In order to test User Agreement editing, you have to select the Edit User Agreement option from the admin panel. You should see a page that will display all available languages and textareas for them. Find the language you have currently selected. For example, I set it for English:

Then, you want to scroll down and press Save. You will have two options available:

There are two options here:

• No, update only, which will save the metadata and do nothing else. Then you will need to create a new account and check if the user license content that is displayed to new users has changed.
• Yes, update and force, which will save the metadata and force all users to accept it again. You can use this and then you have to refresh the page to see the effect.

In the end, you should see this:

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.

[Dawnkai]

When creating this PR, I decided to limit the amount of edits that I made to the code in CRIS and tried to port it as close to 1:1 as possible. This was caused by the time restriction (and busy work week). I have a few potential ideas on how to improve this solution in mind, and I will add them in the code in the form of comments for further potential discussion.

[tdonohue]

@Dawnkai : Thanks for creating this PR! Your approach sounds correct. I'd recommend keeping this PR as close to 1:1 port of code as possible.

That said, you are welcome to add suggestions for changes here for discussion. Or, you also could create a new ticket to describe the improvements (linking them back to this PR). Assuming we all can agree on the improvements, those could always be made in a future, follow-up PR.

(As a sidenote, it looks like some automated tests are failing in this PR. However, the error looks to me like it could be a random failure, so I've triggered a re-run of the tests)

[tdonohue]

@Dawnkai : After rerunning the tests, they are now returning a different error. It looks like this new error is saying that a few unit tests / specs are broken. Could you look into that and get them fixed?

[Dawnkai]

@tdonohue I fixed it. The problem was that in the old version in the tests for the footer component an empty store was mocked, which was a problem - because in CRIS code the component is making a request (and thus fetching non-existing request cache from it). I mocked the SiteService (which is where the request was made) instead. Now it works.

Now all the tests pass.
When it comes to the improvements, since you want this to be merged asap, I will make a separate Issue once this is merged as a field for discussion with my recommendations.

Considering you want 1:1 port (which is of course not fully possible), here is a list of changes I made compared to a "pure" CRIS port:

• I removed all the *ng commands from templates (*ngIf, *ngFor, etc) and replaced them with newer angular format (@if, @for, etc)
• Changed import locations in tests, because some files are in different place in clean DSpace compared to CRIS
• Changed names of the CMS edit and User Agreement edit Components to have Admin prefix (so EditCmsMetadataComponent turns into AdminEditCmsMetedataComponent) in order to match the standard of other components on admin panel
• Added typedocs and docstrings in functions that didn't have them in CRIS (there were a few of them)
• Slightly refactored footer component tests to be more readable and to fix the error I mentioned at the beginning of this comment
• Because getCurrentLanguageCode is an Observable in DSpace and in CRIS it is not, I had to use forkJoin or combineLatest to pull metadata from Site object and current language for displaying CMS metadata and User Agreement
• CRIS is using special layout objects to manage components display on the website (to integrate with CRIS layout tool). These layout object elements are not defined in DSpace and I don't think it's worth moving the whole thing just to make a port, so I simply took what was used (in this case, just the metadata key) from those objects and used it directly in code.

So in terms of functionality, no changes were introduced.

[tdonohue]

Thanks @Dawnkai ! Just to clarify, I realize a 1:1 port will never be fully possible when merging these DSpace-CRIS features back to DSpace.

The Merger Management Team has just made a decision that none of these ports can change the feature's behavior in any significant way. But, we do realize that some code may require updates to be compatible with DSpace... and those small changes for compatibility purposes are welcome.

Thank you for describing the changes you had to make. At a glance, those all look like changes for "compatibility purposes" and would be allowed.

[EikLoe]

@Dawnkai Thanks for the PR. I tested it locally and it worked as inspected. The only issue I had was the display of the cris.cms.home-header:

As someone who don't really know any DSpace-CRIS-System, I wondered, why the position of the header is outside of our normal container-borders, but as this is the described behavior, I'll agree withe PR in general 👍🏾

[vins01-4science]

Hello @Dawnkai, thank you for supporting us with this PR.

The development works as expected, I've only found only few problems:

1. The user agreement says that can be fullfilled in MD style, but in reality it can be fullfilled only with HTML syntax:

I think it's okay, but we may need to explicitly say that.

2. The Save button on end-user-agreement page ( after the login ) is not working anymore. If I click it won't load anything at all, it just shows a loading spinner endlessly ( the patch is sent to the BE, so if I manually change the route it loads the page I requested correctly ). redirect-url

3. I've noticed that also the CMS metadata rendering are not able to display the MD, that it's okay, but I think it would be better to specify that as of now only HTML would be rendered correctly.
4. I think we need to change metadata definition, at least for these ones that are new metadata and easily replaceable by using the dspace schema.

---

cc: @tdonohue @atarix83

[Dawnkai]

Update from me about the progress and response to the comments so far:

@EikLoe Yes, it also irks me, but just as instructed - I tried to limit the altering of CRIS code to the absolute minimum. CRIS has a different format of displaying that section of the page because 4Science is using dynamic components to specify what is to be displayed and in regular DSpace it's hard coded into the HTML. I can apply the container styles to that section of the home page, but only if I am allowed to make such change by @tdonohue.

@vins01-4science Thank you for your feedback. To address your points:

The user agreement says that can be fullfilled in MD style, but in reality it can be fullfilled only with HTML syntax

Are you sure? Remember that you need to set the environment variable called markdown.enabled to true in your config.yml. I set it to true and markdown works on my end:

The Save button on end-user-agreement page ( after the login ) is not working anymore. If I click it won't load anything at all, it just shows a loading spinner endlessly

Yes, that is true. I am trying to fix it now. It seems to be related to caching and subscriptions in the endUserAgreementGuard. It has a function called returnEndUserAgreementUrlTreeOnFalse which detects if a user has accepted the end user agreement. For some reason the request that is being sent in that function to the store has state set to Pending and it never finishes. Initially I thought it was because the request was cached, so I disabled caching, but that broke even more things, so I have to dig deeper.

I think we need to change metadata definition, at least for these ones that are new metadata and easily replaceable by using the dspace schema.

I edited the metadata used for CMS on both frontend and backend PR to use dspace schema instead of cris schema.

[tdonohue]

@Dawnkai : I've not had time to look at this PR myself, so I'm unclear on the exact details of the display issues that you and @EikLoe are referencing (and the screenshot @EikLoe previously shared isn't loading for me).

However, to clarify, you are welcome to make any changes that help this feature to work better within DSpace. So, if style changes are necessary, please make them. The only changes that the Merger Management Team will not accept are changing the feature behavior... the feature's behavior must remain "as-is". In other words, we want to avoid redesign of the feature itself during migration from DSpace-CRIS to DSpace.

Hopefully that clarifies things. But, if I'm misunderstanding the question, then please let me know.

[EikLoe]

(and the screenshot @EikLoe #5106 (comment) isn't loading for me).

@tdonohue Oh, sorry. I updated my comment. It should be displayed correctly now.

[tdonohue]

@Dawnkai: Based on @EikLoe 's updated screenshot, I think that display is also incorrect. Obviously, the header shouldn't appear in a sidebar, so that's something that should be fixed within this PR. So, please do update this PR to get the header to display in the proper location for DSpace.

[github-actions]

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

[tdonohue]

@Dawnkai : Could we get this PR and the backend PR updated / cleaned up (both currently have merge conflicts)? Our 10.0 feature deadline is Friday, and I'd like to see if we can move this forward. Thanks!

[Dawnkai]

@tdonohue I am updating both frontend and backend now.
I managed to fix the styling issue mentioned by EikLoe. Now the margins are applied properly:

As for the issue mentioned by Vincenzo, I don't have good news.
It seems that there is some issue with requests deep within DSpace (without CRIS). When you force users to re-accept the end user agreement and they do it while their session is active, the entire User object in the store becomes invalidated - then frontend triggers the this.epersonService.findById function many times, which results in the request to the backend being marked as Stale endlessly, and then because of:

const response$: Observable<RemoteData<T>> = this.rdbService.buildSingle<T>(requestHref$, ...linksToFollow).pipe(
      // This skip ensures that if a stale object is present in the cache when you do a
      // call it isn't immediately returned, but we wait until the remote data for the new request
      // is created. If useCachedVersionIfAvailable is false it also ensures you don't get a
      // cached completed object
      skipWhile((rd: RemoteData<T>) => rd.isStale || (!useCachedVersionIfAvailable && rd.lastUpdated < startTime)),
      this.reRequestStaleRemoteData(reRequestOnStale, () =>
        this.findByHref(href$, useCachedVersionIfAvailable, reRequestOnStale, ...linksToFollow)),
    );

The request for new user object never finishes. Fixing this without affecting other components is problematic. I asked another coworker of mine who is much better at angular than me for help, but I am not sure if we will be able to get it fixed by Friday.

The only "fix" that works is replacing this fragment in the submit function called when you accept the End User Agreement:

if (isNotEmpty(redirectUrl)) {
     this.router.navigateByUrl(decodeURIComponent(redirectUrl));
}

which is just redirecting the user to the proper page after they accepted the agreement, into a hard redirect, which will still do the redirect, but also refresh the page:

if (isNotEmpty(redirectUrl)) {
    const fullRedirectUrl = `${this.hardRedirectService.getCurrentOrigin()}${decodeURIComponent(redirectUrl)}`;
    this.hardRedirectService.redirect(fullRedirectUrl);
}

This will force the frontend to reload the user object and everything works well from that point onwards. However, since that is a change (albeit small) to the DSpace functionality, I need confirmation if that is okay. If not, then we will just keep trying to find the source of the issue with my coworker and try to implement a proper fix.

[github-actions]

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

[Dawnkai]

Okay, so:
As agreed on Developer's Meeting (26th of March 2026) with @tdonohue I had a look on a PR that attempts to fix the same issue I reported:
#5099
Unfortunately, while the fix in that PR works for infinite loading, it breaks other functionalities as Marcin Miłosz has reported in that PR's comments. My coworker also tested it and confirmed that it sadly does not fully fix the problem.

He also found the culprit and has come up with a fix. The issue is caused by recursive calls to /eperson endpoint that are cancelled all at once in RequestService but still inserted into the cache, which results in that permanent ResponsePending status. He also found out that this isn't the first time this issue happens, as he found other attempts at fixing this in git history.

In any case, we decided to go forward with the fix I proposed: using hard redirect instead of regular nagivate function when user accepts the license. This effectively refreshes the store and stops the recursive chain from happening. I also used URLCombiner (proposed by Art I believe).

My coworker has a better fix for this problem, however it can potentially contaminate other components, so he will simply make a new bug Issue where he will describe the problem in more detail and provide a fix. Then hopefully we can get it tested thoroughly since we won't be pressured by the DSpace 10 Release Deadline.

I tried moving around the site after accepting the user agreement with the hard redirect and found no issues, but if someone wants to give it another test that would be nice. If not then that is all we can do for now.

Thanks to everyone involved for the feedback and helpful tips again.

[tdonohue]

Thanks for the update @Dawnkai ! That all sounds good to me. I'm also glad to hear your colleague has found a possible fix & look forward to seeing that bug fix PR once it's ready.

I'll try to test this PR later today myself, so that we can try to get this feature into 10.0. Even if it isn't possible to merge today, the Merger Management Team already approved an extension for merger-related PRs until next Wednesday. So, if you can help to continue to address any feedback until then, I'll also do my best to ensure this keeps moving forward so that we can get it into 10.0.

Thanks again.