New menu entries for creating sub-objects on community and collection pages

[EikLoe]

References

Add references/links to any related issues or PRs. These may include:

• Fixes New "Add sub-objects entry" in edit-menus on community or collection pages #5825 and Collection submit button #2556

Description

This PR adds new entries to the dso-edit menus on community and collection pages. Those entries allow you to directly add sub-objects such as communities or collections to an existing community or submit a new item in a collection.
In addition a new Submit item button will be added to the collection page, if collection.showSubmitButton is set to true.
If you're a logged in as a submitter and your frontend is configured to show the submit button the collection page should look like this:

If collection.showSubmitButton is set to false, the Submit item functionality is hidden in the dso-edit menu of the collection page:

Instructions for Reviewers

Please add a more detailed description of the changes made by your PR. At a minimum, providing a bulleted list of changes in your PR is helpful to reviewers.

List of changes in this PR:

• Added new AddSubObjectsMenuProvider in order to allow directly adding subcollections or subcommunities to an existing community
• Added new SubmitNewItemMenuProvider to allow directly submitting items via the dso-edit menu on collection pages.
• Created a new configuration entry for showing a submit button on collection pages
• Added the new submit button on collection pages
• Created and updated spec and e2e tests.

Include guidance for how to test or review your PR. This may include: steps to reproduce a bug, screenshots or description of a new feature, or reasons behind specific changes.

1. Login as a community administrator and navigate to the community where you have admin privileges to.
2. Make sure, you see the new Add community and Add collection entries in the dso-edit menu and test their functionality
3. Navigate to a collection where you have at least submitter privileges: make sure you can see the new Add item entry in the dso-edit menu.
4. Add the following configuration to your config.yml and rebuild your frontend:

collection:
  showSubmitButton: true

5. Navigate to a collection where you have at least submitter privileges: make sure, the new Submit item button appears on the collection page. The menu entry should not be visible any more.

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.

[EikLoe]

I'm still not sure, whether we want the Submit button to display the text "Submit Publication" or "Submit JournalIssue" on collections with the specific entity types.

[github-actions]

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

[alexandrevryghem]

@EikLoe: Thnx for this PR, I've tested the changes and they look good. I added some small inline comments regarding small improvements

I did however notice that you added an option to display the "Add an item" option as a separate button. That code should be removed, because this is something that can easily be achieved by moving that provider to be at the same level as the DsoOptionMenuProvider like this:

[MenuID.DSO_EDIT]: [
    SubmitNewItemMenuProvider.onRoute(
      MenuRoute.COLLECTION_PAGE,
    ),
    DsoOptionMenuProvider.withSubs([
      EditItemMenuProvider.onRoute(
        MenuRoute.ITEM_PAGE,
      ),
      SubscribeMenuProvider.onRoute(
        MenuRoute.COMMUNITY_PAGE,
        MenuRoute.COLLECTION_PAGE,
      ),
...

[EikLoe]

Hi @alexandrevryghem ,
thanks for your review. I addressed most of your feedback. I'm still unsure how to solve the submit-button on collection pages issue. As @lgeggleston wrote in #2556:

But for Collection -> Submit Item, it would be important to enable a more prominent button directly on the page, since part of the intention is to help users that are less familiar with existing administrative options.
There was also a suggestion the UI could be configurable for collection pages (so the Submit button could either appear directly on the page, And/Or in options menu)

I'm not sure how to address the problem with the configurable option by adding it twice to the app.menu.ts Both buttons would need slightly different attributes, which would require two providers: one for the dso-edit-menu entry and one for the collection-page. The other option is, implementing the configuration check in the app.menu.ts.
Also the button added via the dso-edit-menu would just be a small + next to the edit menu:

Would this be prominent enough?

[alexandrevryghem]

@EikLoe: Implementing that button as a menu provider is in my opinion already enough to make it configurable. Based on that comment I assume the default behavior is displaying it like this as a seperate button, and if someone want to customize their DSpace to show the option under the regular menu this can easily be achieved by moving the provider to the dso menu

About the issue if it would be prominent enough we could update the DsoEditMenuSectionComponent to show the text like this as well by removing the sr-only (this should only be done in desktop mode though, in mobile view I would still only render the icon):

We should propably also introduce a new MenuItemType#ICON for example that people can use when they don't want to display the text in desktop and mobile mode, bcause otherwise they might leave the property LinkMenuItemModel#text empty to achieve that result, which would be bad for accessibility. We could already use this new MenuItemType for the DsoOptionMenuProvider for example

[EikLoe]

@alexandrevryghem

We should propably also introduce a new MenuItemType#ICON for example that people can use when they don't want to display the text in desktop and mobile mode

This a good idea! But isn't the new MenuItemType#ICON something we would handle on the PartialMenuSection level, because the icon information does not exist in the ItemModel. Also, this might be interesting for multiple link types such as LINK, TEXT, ONCLICK or perhaps even EXTERNAL. Or what do you think?

[github-actions]

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

[alexandrevryghem]

@EikLoe: This would indeed be best handled in the PartialMenuSection, we could simply add a boolean renderIconOnly, this way we don't have to create new dynamic components & menu item types for all these new MenuItemType#ICON_LINK, ... options

[EikLoe]

I added the renderIconOnly boolean and implemented it in the dso-edit-menu-section component.
We could add the following line to the dso-edit-menu-expandable-section.component.html, thus allowing folks to easly display the text of the Options menu as well:

        <span [class.sr-only]="section.renderIconOnly" >{{itemModel.text | translate}}</span>

(the default would be section.renderIconOnly=true of course)
What do you think?

[alexandrevryghem]

@EikLoe: I don't have a lot of time to test it today but it looks good 👌