Admin Screen to manage Suggested Solr fields

[epugh]

I don't yet have practical experience on how much we'll use the suggested Solre fields feature. However, if we do start using them, it would be nice to be able to have an admin interface to pick them. Over in Quepid land, we actually query the underlying search engine (Solr, Elasticsearch) to get a list of fields, and then have a filtering picker to let the user pick the one.

Otherwise we are doing:

curl -S -X PUT -H "Content-Type: application/json" -d '{"name":"product_type"}' http://localhost:9000/api/v1/${SOLR_INDEX_ID}/suggested-solr-field

[renekrie]

As far as I can see, the majority of UP/DOWN/FILTER rules uses fields. However, so far we could avoid coupling SMUI with Solr. Maybe, that's again more like a script, which provides the fields and which could be adjusted to the different Solr access scenarios (like the rule deployment).

Also, opening up a field for use in search management should indeed have very restricted access in order to keep up control - we'd definitely need an admin role for it.

[mkr]

Tight coupling has its advantages as we would allow for much more functionality around immediate feedback/preview (things like typos in filter expressions that lead to syntactic errors, see immediately how many documents does an expression capture etc.). On the other hand, I could imagine a fixed list of fields that one needs to pick from can be more helpful than suggesting the potentially hundreds of (dynamic) fields.

[renekrie]

Yes, I can see that. Maybe just having an abstraction SearchEngine solves the problem.

[pbartusch]

I agree:

• with @epugh : Field names for the search engine (like Solr) should be suggested from the search engine itself.
• with @mkr : That there is potential to improve SMUI while coupling SMUI with the search engine. But: This coupling should be very loose and only optional - which should work for the suggested fields.

So I see 2 contact points, where SMUI uses the specific search engine:

1. Supporting the Search Manager: should be optional, e.g. when suggesting (Solr) fields, validation, maybe a preview in the future
2. Exporting the rules.txt file and deploy it to the search engine

As for the latter, I see #56 connected to this issue.

[renekrie]

On this note, I still think that using templates (#56 (comment)) could be a great solution here. Not exactly a field list, but something that uses fields and that could provide us with search-engine specific query syntax. We could give the admin user the powers to manage templates (for whatever complexity of the query) and generate the UI from parameter documentation.

[epugh]

As a baby step, I'm working through adding the "suggested fields" list to the UI. Down the road, if we have a better solution we can always get rid of this... But at least we'll make it simpler to configure/edit/delete the suggested fields.

I'm building it as part of PR #80, though I could branch off of that.. It assumes that you already have the Admin screens....

[epugh]

Took some work to figure out routing, and I don't love the route I picked, but it's working: