Support Search Facet customizations per Community or Collection

[alawvt]

Is your feature request related to a problem? Please describe. In DSpace 5 and 6 XMLUI one can specify facet and search filters per community or collection. This is especially useful for collections with unique metadata such as patents (inventor, patent classifications, etc.) and theses (e.g. Advisor, degree, etc.). Examples of these in VTechWorks are https://vtechworks.lib.vt.edu/handle/10919/72294 and https://vtechworks.lib.vt.edu/handle/10919/5534. Please support this functionality in DSpace 7.

Describe the solution you'd like Ideally, besides providing this functionality, there would be instructions for converting the configuration in discovery.xml to the new configuration.

Describe alternatives or workarounds you've considered A clear and concise description of any alternative solutions or features you've considered.

Additional context Add any other context or screenshots about the feature request here. This could also be advantageous for collections with entities enabled. For example People or OrgUnit collections would require unique facets.

[kshepherd]

Note, there is still a commented-out line in the spring configuration that implies it is still possible to scope by community or collection handle:

<!--<entry key="123456789/7621" value-ref="defaultConfiguration"/>-->

Until this is fixed we should add some extra comments to note the feature is to come in a future release, or remove the line.

[tdonohue]

@kshepherd : I honestly don't know whether this works in DSpace 7 yet (or not). So, it's possible it works but isn't fully documented yet.

So, the first task in this ticket is to determine if there's a way to already do this in DSpace 7 (and if so, to document it). I haven't had a chance to test that out yet, but you've found a clue that implies it might work: https://github.com/DSpace/DSpace/blob/main/dspace/config/spring/api/discovery.xml#L59

[tdonohue]

While this feature looks like it's still supported in discovery.xml (and in the Java code), I cannot seem to get it to work to change the UI search display for specific Communities/Collections. So, I'm recategorizing this as a "bug" and moving it over to 7.4.

[abollini]

It is not trivial. The current REST contract says https://github.com/DSpace/RestContract/blob/main/search-endpoint.md#search-endpoint

configuration: The name of a Discovery configuration that should be used by this search. If the provided scope already has a specific Discovery configuration defined, than this parameter will be ignored. Two special configurations always exists workspace and workflow. These configuration are used by the MyDSpace functionality, more details at the bottom of this page.

but this is currently not respected by the REST side that gives precedence to the configuration name, see https://github.com/DSpace/DSpace/blob/63b1ff825b3f2afc3c706d7101b213bbf06bfec3/dspace-api/src/main/java/org/dspace/discovery/configuration/DiscoveryConfigurationService.java#L72

BUT this is also required as in dspace 7 we have started to use discovery for other purpose than public search. In these scenarios (mydspace, administrative search, etc.) the special configuration MUST have priority over any scope definition.

A way to solve this could be to change the rest contract and the implementation to always use both the configuration name than the scope to determine which discovery configuration should be used

The configuration parameter will be used as "prefix" and the final configuration to use will be configuration-param.scope with fallback to configuration-param, default if a such configuration is not defined.

To fix that only changes on the REST contract and REST implementation are required, we can work on that our estimation that include good test coverage is 20 hours

[abollini]

Please keep in mind that this task is only about the Search constrained to a community/collection. In previous DSpace version there were specific widget in the community/collection home page that are NOT yet implemented in DSpace 7 such as the faceting and the search inside this com/coll. For these aspects we should separate tickets would be appropriate

[tdonohue]

@abollini : Your estimate sounds reasonable for making this work on the /search page/features. I agree that changes to the community/collection homepages should be treated as a separate ticket & should not be included in this ticket.

Assigning to you for your team to work on for 7.5