-
Notifications
You must be signed in to change notification settings - Fork 8.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Cases] Deprecate query params from the find cases API #151833
Comments
Pinging @elastic/response-ops (Team:ResponseOps) |
Pinging @elastic/response-ops-cases (Feature:Cases) |
Just a quick reminder that if this change is implemented, the API spec ought to have "deprecated: true" added to these parameters in https://github.com/elastic/kibana/blob/main/x-pack/plugins/cases/docs/openapi/paths/s%40%7Bspaceid%7D%40api%40cases%40_find.yaml |
Thank you @lcawl! Good point. |
If there's not a strong business need to have these params deprecating/removing them makes sense. But another option is to limit these to a small set of known fields if we expect users might get benefit from it. |
What is telemetry telling us about customer usage here, @cnasikas ? Rudolf´s suggested change would give us a more nuanced approach here than just deprecation |
Hey @heespi! We do not have telemetry for the use of these specific query parameters. We have telemetry for endpoint usage in general. They or may not use the query parameters. Limiting to a small set of known fields makes sense and probably we should do it for the |
Agreed that it could lead to a breaking change, so we should follow process. Still, it does sound like a better user experience for ,hopefully, the majority of our users. |
|
The find cases API allows searching all case fields that are persistent in ES. This means that all fields should remain in the mapping to be indexable. If we want to remove fields from the mapping it will lead to a breaking change. For that reason, we should deprecate the following query parameters of the find cases API:
searchFields
fields
The text was updated successfully, but these errors were encountered: