Make filter options customisable

[Angi-Kinas]

Proposal: Make filter customizable through default.toml. Once this PR is merged, one will be able to decide which advanced filters to include in the application. This can be done by specifiying the "advanced_filters" in the default.toml, like so:
advanced_filters = ['publisher', 'format', 'publicationYear', 'topic', 'isSpatial', 'license']
if advanced_filters are no specified by the user(admin), the one above will be used.
These are the possible filters: 'publisher', 'format', 'publicationYear', 'standard', 'inspireKeyword', 'topic', 'isSpatial', 'license'

Screenshots:
with all filters:

customised version:

[github-actions]

Affected libs: util-app-config, feature-record, feature-router, feature-map, feature-dataviz, util-i18n, feature-catalog, feature-search, feature-editor, feature-auth, ui-elements, ui-catalog, ui-search, ui-dataviz, ui-inputs,
Affected apps: datahub, metadata-editor, demo, webcomponents, search, map-viewer, metadata-converter, datafeeder,

• 🚀 Build and deploy storybook and demo on GitHub Pages
• 📦 Build and push affected docker images

[jahow]

A few things to address and that's it, very good work!

[jahow]

• I think we should show the two first fields when the block is collapsed, instead of hardcoding field names
• the logic for building the full class attribute would maybe be better in the TS file, and it would be easier to test as well

[jahow]

we shouldn't do any mapping with field names here, only the fields service has this power :)

[jahow]

Suggested change

	# available filters: 'organisation', 'format', 'publicationYear', 'standard', 'inspireKeyword', 'topic', 'spatial', 'license'
	custom_filters = ['organisation', 'format', 'publicationYear', 'standard', 'inspireKeyword', 'topic', 'spatial', 'license']
	# The advanced search filters available to the user can be customized with this setting.
	# The following fields can be used for filtering: 'publisher', 'format', 'publicationYear', 'standard', 'inspireKeyword', 'topic', 'isSpatial', 'license'
	# advanced_filters = ['publisher', 'format', 'publicationYear', 'topic', 'spatial', 'license']

Note: since this is an optional key, it should be commented out in the toml file and the default value should be written in the app (datahub in this case).

[jahow]

use marker for i18n

[fgravin]

Just a comment without doing a review.
A proposal of the new configuration inputs should be provided in the description of the PR.
The configuration is quite sensitive as it has to be human manageable.
I suggest that everyone time we touch the configuration schema, we propose the change within the PR, so we can discuss it even though we are not looking at the code.
Thanks 🤗

[Angi-Kinas]

@fgravin I updated the description of the PR. Let me know if there is something to change/add.

[fgravin]

@fgravin I updated the description of the PR. Let me know if there is something to change/add.

Great thanks.
I wonder if a user add a filter which is not in the list, what would happen ?
BTW, I think that a user should be able to add any field of the domain metadataRecord model as a filter, it should perform a basic term aggregation. I don't know how this is handled right now, could be addressed when the need appear later on though.
👍

[Angi-Kinas]

@fgravin good question. When the user adds a filter that's not in the list, there will be an Error in the console and the app is not usable anymore:

@jahow and I decided that this is ok for now. What do you think?

[jahow]

BTW, I think that a user should be able to add any field of the domain metadataRecord model as a filter, it should perform a basic term aggregation. I don't know how this is handled right now, could be addressed when the need appear later on though.

That might be doable yes, if the need arise we could do it! E.g. filter on uuid, title, links etc.

[fgravin]

@jahow and I decided that this is ok for now. What do you think?

I think that it should not happen, shouldn't it ?
An error in the config should not break the application IMO, I don't know what is the behavior for the other fields.
Might not be hard to check for the error and add a warning in the console at least ?

[jahow]

@jahow and I decided that this is ok for now. What do you think?

I think that it should not happen, shouldn't it ? An error in the config should not break the application IMO, I don't know what is the behavior for the other fields. Might not be hard to check for the error and add a warning in the console at least ?

Hmm, I would say an error in the config should break everything because the configuration is expected to be valid at runtime. At load time we check if every required configuration setting is there, but we cannot know yet if one of the filters is invalid or not. If an invalid field is specified then an error is thrown in the console, the only issue here is that the application still loads and kind of look normal, so an administrator might not realize that they made a mistake in the config.

The best solution IMO would be to have a strong error message showing up like: "WARNING: the configuration is invalid, the application cannot run" or something like that.