User story #8563
Updated by François ARMAND about 8 years ago
The current "quick search" bar is very limited, and only allows to search for nodes, by hostname. But of course we also want to search for all the directives using a given parameters, or touching a given path, or all the rules embeding a directive, etc - and of course, when an interesting item is found, we want to jump to its corresponding definition.
Contrary to usual rules, we proposed to build such quicksearch in Rudder 3.1 BUT behind a feature switch guard (disabled by default). The idea is that that feature is a major UX help but it does not touch any sensitive part of servers configuration, and is read-only on everything (contrary to the search used for group, for example) - it's just a new way to query information.
On the feature itself, we would like to keep it simple, what means, among other things, not be able to "and" or "or" things. In fact, the proposed quicksearch would be better view as big filter on Nodes, Groups, Directives, Parameters and Rules, we the whole query phrase is exactly looked for in the objects and only the one matching it are kept. That would also helps keep the response time low, and in such feature, it is much more important to be able to quickly iterate between queries to get what we are looking for than to be able to build the exact query matching the exact subset of elements we need.
For the same reason, only a subset of objects properties will be look for (typically, given the current state of Rudder, allowing to search on node by software would notably complexify the query engine and lower performance).
Queries can be refined by providing a subset of objects or attributes to look into. Attribute names used in REST API responses would be used for that.
For example, to only look for nodes with hostname containing "mysubdomain" you could write:
<pre>
mysubdomain object:node attribute:hostname
</pre>
And if you want to only get the rules and groups with "security policy" in their name or description, you could write:
<pre>
security policy object:group object:rule attribute:displayName attribute:description attribute:longDescription attribute:shortDescription
</pre>
Or more succintly:
<pre>
security policy object:group,rule attribute:displayName,description,longDescription,shortDescription
</pre>
All the object/attributes filters name case insensitive, and we will also configure aliases, so that you could write the previous request (yes, I tend to make object in their plural form):
<pre>
security policy object:groups,rules attribute:name,description
</pre>
Screenshot of the prototype is attached.
Some question:
- what are the correct names for filters? "object" feels okayish. Could be "type". "attribute" is quite long. "key" is short, but not very self-descriptive. Or perhaps just have a "filter" or "only" keyword, and the engine find by itself if it's an object or an attribute ?
- I'm pretty sure we want to limit the number of results by type, be have a chance to see the rules even if 5000 nodes matches. In the example, I limited to 3 for the example, but 50 or 100 seems better. What do you think ?
- as explained, I selected some attribute base on technical constraints (the list is below). Are you ok with the list ?
- what is the correct way to let an user discover what is searchable, and how? I'm thinking to two may ideas:
1/ have a query form UI displayed when the focus is on the input field, withe a tree clickable for each object, letting the user check what he wants for each (defaults: everything checked, clicking on an object select/unselect all its attributes). Of course, one would be able to also just write the filter by hand once he learned their name.
2/ just have a documentation openable near the field, with all attributes and their names and aliases.
In all case, it would be better to have completion on object/attribute names.
So, any feedback would be very welcomed!
!rudder_quicksearch_ex2_2016-06-17_16-35-07.jpg! !rudder_quicksearch_ex1_2016-06-17_16-35-07.jpg!