Fix/5524 collection selector hide communities

[shernandez-dev]

References

• Fixes Administrator reports + Metadata Queries: Communities appear in the Collection Selector but can not be selected #5524
• Fixes Administrator Reports - Metadata Query: "Whole Repository" and specific collections can be selected simultaneously in Collection Selector #5883

Description

Replaces the flat <select> list in the Metadata Query Report Collection Selector with a grouped tree-style selector that shows communities as non-selectable headers and collections as clickable options, eliminating the confusion caused by unselectable community entries mixed with collections.

Instructions for Reviewers

Root Cause

The loadCollections() method in FilteredItemsComponent built a flat OptionVO[] array by mixing communities (marked disabled=true) and collections together in a single <select multiple> element. Communities appeared as entries that users could not select, and when many communities appeared at the top of the list, it was unclear whether anything could be selected at all.

Changes

• filtered-items.component.ts:

  • Added CollectionGroup interface to group collections under their parent community
  • Added collectionGroups: CollectionGroup[] property
  • Refactored loadCollections() to no longer push communities as disabled <option> entries — instead, each community becomes a group header with its collections as selectable items
  • Added toggleCollection(collectionId: string) method to handle multi-selection via click
  • Added isCollectionSelected(collectionId: string) method to track selected state
  • collections: OptionVO[] is still maintained for form compatibility with toQueryString()
  • Updated toggleCollection() to enforce mutual exclusion between "Whole Repository" and specific collections — selecting one automatically deselects the other (Administrator Reports - Metadata Query: "Whole Repository" and specific collections can be selected simultaneously in Collection Selector #5883)

• filtered-items.component.html:

  • Replaced <select multiple> with a custom list using Bootstrap list-group-item buttons
  • Communities rendered as text-muted small non-interactive headers
  • Collections rendered as fw-bold clickable buttons with bg-primary highlight on selection
  • Follows the same visual pattern used in the existing Edit Item / Move Item collection selector (dso-selector), as suggested in the issue discussion. A full reuse of the dso-selector component was considered but not pursued, as that component is designed for single selection and would require significant refactoring to support multi-selection. Instead, the same visual hierarchy (community as breadcrumb context, collection as bold selectable item) was replicated using standard Bootstrap list-group-item buttons, keeping the change isolated to this component.

• filtered-items.component.spec.ts:

  • Added 14 unit tests covering loadCollections(), toggleCollection(), and isCollectionSelected()

Before

Communities and collections mixed in a flat <select> list. Communities appeared as unselectable entries, making it unclear what could be selected:

After

Communities shown as non-interactive group headers (grey, small text). Collections shown as bold clickable buttons with highlight on selection:

Note: screenshot taken from a local instance in Spanish. Collection names and community names will appear in the repository's configured language.

How to Test

1. Log in as an admin
2. Navigate to Reports → Metadata Query
3. Open the Collection Selector panel
4. Verify communities appear as non-clickable grey headers
5. Verify collections appear as bold clickable buttons below each community
6. Click one or more collections and verify they highlight correctly
7. Run a query with selected collections and verify results are filtered correctly

Reproduced and confirmed on DSpace 9.x and DSpace 10.0 (as reported in the original issue).

Checklist

• My PR is created against the main branch
• My PR is small in size (3 files modified)
• My PR passes ESLint — npm run lint fails with a pre-existing error unrelated to this fix (src/themes/custom/eager-theme-components.ts). ESLint was run directly on the 3 modified files and passes without errors.
• My PR doesn’t introduce circular dependencies (verified via npx madge --circular on the affected directory)
• My PR includes TypeDoc comments for new methods
• My PR passes all specs/tests and includes new/updated specs
• My PR includes details on how to test it
• My PR uses i18n keys (no hardcoded English text added)

[lgeggleston]

@shernandez-dev Thanks for your contribution, and identifying the secondary issue on this component!

@tinsch Since you reported the original issue about the collection selector, would you by chance be interested in testing this to confirm if this addresses the usability concerns appropriately?

[tinsch]

@lgeggleston yes I am happy to test this 👍

[tinsch]

@shernandez-dev thanks for the fix! I tested it and the UX is much better now. The tree structure between communities and collections is visible and it is clear only collections are selectable. The toggle between "Whole repository" und collections also works well 👍

[MMilosz]

While the grouped presentation is much clearer than the previous flat list. However, I noticed one usability regression in the new design

The previous <select multiple> allowed users to select large numbers of collections using:

• Shift-click
• Ctrl/Cmd-click
• Mouse drag selection
• Keyboard selection (accessibility!)

With the new button-based selector, we lose all of these and can only click every collection individually, which feels like a significant usability regression

Before

Tested on demo.dspace.org

before.webm

After

after.webm