UI Filtering usage in Angular slight Improvement

[naris]

Overview of the feature request

Currently Filtering has kinda sorta been somewhat implemented in the Angular client. If there is a filter in the URL it adds a notice that a filter has been set and has X buttons to clear some or all of the filters. However, there is no way in the UI to add a filter, you have to add the filters by editing the URL in the browser's address bar (with %5B and %5D around certain parts of the filter) :/

There is a FilterComponent in the generated code that is added to each entity list page with this html: <jhi-filter [filters]="filters"></jhi-filter>

A simplistic implementation that would make the filters at least somewhat usable until a component can be decided upon would be to at least have the FilterComponent generate an input control to type the search value into per field with a dropdown to select the condition (such as equals,contains,in,greaterThan,etc.). An even simpler approach would to be at least have 1 input control that the user could manually type the entire filter condition(s) into.

Motivation for or Use Case

This would make the filter feature at least somewhat accessible and usable until a filter component is selected and a fuller featured, umm, feature can be added

Related issues or PR

UI Filtering usage in Angular #20189 Display a link to a filtered view for the Many Side of a OneToMany / ManyToOne relationship on the One side #18370

• [X] Checking this box is mandatory (this is just to show you read everything)

[OmarHawk]

We have implemented such a thing as you proposed by ourselves for our own application using Blueprint mechanisms so that users can easily define filters based on the available operations and fields to filter for and save them persistently for themselves and globally (for other users) for frequent usage...

What we have noticed during that is that the filter capabilities on the backend side are kind of limited, especially when it comes to filtering based on foreign key attributes -there you can basically only filter by id...

So our next evolution of that is that we make our filter generator generate elastic search query syntax instead, as this is way more flexible without having the restrictions on the foreign key attributes.

Thought I share that with you to give you a rough of what this could be extended with.

[naris]

We have implemented such a thing as you proposed by ourselves for our own application using Blueprint mechanisms so that users can easily define filters based on the available operations and fields to filter for and save them persistently for themselves and globally (for other users) for frequent usage...

What we have noticed during that is that the filter capabilities on the backend side are kind of limited, especially when it comes to filtering based on foreign key attributes -there you can basically only filter by id...

So our next evolution of that is that we make our filter generator generate elastic search query syntax instead, as this is way more flexible without having the restrictions on the foreign key attributes.

Thought I share that with you to give you a rough of what this could be extended with.

We don't actually use any of the generated entity screens in our application, as they have very limited usage anyway, and have changed the entire Entity dropdown menu as ROLE_ADMIN only.

We used to use the primeng blueprint where all the filter functionality worked very well. Unfortunately this blueprint no longer works with either the v8.x version of jhipster and only the old version works with jhipster v7.x and there is pretty much no support for this blueprint or, really, using any blueprints. I had to remove the blueprint in order to migrate to jhipster v8.

Also, even if we were to use the entity screens, filtering on foreign keys would not be the primary use, simply filtering on the actual data in the table itself would be good enough. I don't understand the insistence on filtering only on foreign keys and not the actual data in the table.

The main reason I created this feature request is that I found several questions and threads asking about it (here, in stack exchange and internet searches) and this would at least make the built in filters at least somewhat useable. It would also be helpful to be able to perform administrative table maintenance on the tables if you could filter them, which is what we would use them for.

[OmarHawk]

I don't understand the insistence on filtering only on foreign keys and not the actual data in the table.

I didn't say we only want to filter for foreign key data, but I rather said, that this does not work out of the box (but is a requirement for us that we need to have this working as well together with filtering for the actual table data) ;-)