Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Validate `query` field when creating roles #46275
In the current implementation, the validation of the role query
This commit adds validation for the role query when creating a role
For validation, the query is evaluated (if not a template), parsed to build the
I'm very excited for this, as I can use it to resolve elastic/kibana#36529.
I started testing against this PR, and I can see the validation working:
(aside: what's the difference between a
My question for you: Is there a way I can programmatically determine if the query validation failed, or if there was a different cause for the failure? I'd rather surface a more user-friendly message in the UI, as there are potentially a lot of fields in play on the Role Management screen, and the errors returned from ES in this scenario don't always offer enough context to make them actionable. For example, if there are two or more DLS queries defined on the role, is there a way to know which one failed?
If not, then I have another question: would it be possible to extract this new validation logic to a dedicated API call as well, so that I can use it independently of the create/update role APIs? That would allow me to highlight the offending query in the UI, so that it's immediately obvious to the user that a query is malformed, and even which query is malformed. I realize this might not be your preferred route, as it'd really only be useful to Kibana...I'm open to other suggestions as well!
Thank you for testing this, appreciate your feedback!
It's a little confusing for me too. We have been using at places for parsing errors and sometimes
Right now there is no way programmatically to determine if the query validation failed.
For the position of index privilege where the query validation failed we can do that as it is an array.
I think adding a new API only for validation is something we might not want to do as it is very specific to the presentation layer and we have avoided doing that till now.
Few things UI could do more:
Yep, I assumed that was the case, but there's no harm in asking
Yeah, this is a quick win for us, good suggestion.
I think this would be ideal, but that would be quite a bit of work for us, and not something I could take on in the near future.