Skip to content
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

[Actions] [7.x] Convert all savedObjectClient.get() calls to use savedObjectClient.resolve and handle the response appropriately #107069

Closed
chrisronline opened this issue Jul 28, 2021 · 3 comments
Assignees
Labels
Feature:Actions/ConnectorTypes Issues related to specific Connector Types on the Actions Framework Feature:Actions Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams)

Comments

@chrisronline
Copy link
Contributor

chrisronline commented Jul 28, 2021

(No longer) Blocked

#106897 needs to be merged before this work can be finished. - has been merged!

Summary

In #100067, we need to ensure that all rule and connector saved objects are shareable. Part of this effort involves needing to regenerate saved object IDs to guarantee uniqueness across all spaces (which is currently not guaranteed). This affects existing saved objects, as every saved object will receive a new ID as part of this effort and the new .resolve() saved objects API is designed to give insight into that process for a specific saved object.

This new API not only returns the saved object (it will attempt to find the actual saved object even if the consumer provides the outdated ID) but also information on the new and old saved object IDs and based on the response, plugin owners are expected to provide a quality UX and let the user know of any actions they need to take (such as updating bookmarks, etc). (#95958 is a good reference PR for the expected type of change)

As a result of the above, various plugin's server code needs to convert to using this new saved object .resolve API. We also need to ensure the UI handles showing the user an appropriate message regarding this situation. Luckily, the core/security team built out shareable React components to do that and a good example of how is here

For the sake of consistency, I recommend all .get() calls change to .resolve() (instead of attempting to only find the places where we need to change to .resolve()). It's unclear when/if the .resolve() API deprecates, but if/when that happens, we can change all .resolve() back to .get() in one move.

List of affected areas of code

As a result of the above, the actions plugin's server code needs to convert to using this new saved object .resolve API. Our PoC PR revealed a few places where we need to do this:

There may be more places, and changes to the above listed files might mean additional changes to callers of the above code paths.

When and backporting

This work needs to be done before 8.0. Most of the work can be backported as well. Because #107083 will handle changing the namespaceType, this PR will just need to ensure the .resolve() changes do not break existing behavior.

@chrisronline chrisronline added Feature:Actions Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams) Feature:Actions/ConnectorTypes Issues related to specific Connector Types on the Actions Framework labels Jul 28, 2021
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-alerting-services (Team:Alerting Services)

@chrisronline chrisronline changed the title [Actions] Convert all savedObjectClient.get() calls to use savedObjectClient.resolve and handle the response appropriately [Actions] [7.x] Convert all savedObjectClient.get() calls to use savedObjectClient.resolve and handle the response appropriately Jul 28, 2021
@ymao1 ymao1 self-assigned this Jul 30, 2021
@ymao1
Copy link
Contributor

ymao1 commented Aug 3, 2021

Currently, we store transient action_task_params in the Kibana index. These documents reference the associated connector SO ID in its actionId field, as well as the related alert SO ID in its relatedSavedObjects array. Since neither of these are in the SO references array, the SO IDs will become outdated if Kibana is upgraded before a queued action is run by task manager.

We could update these documents in order to use the references array but since they are temporary documents, it seems like it would be ok to just use .resolve to resolve the outdated connector SO ID:

  • Rule runs and schedules an action with action_task_params with actionId: abc and relatedSavedObject alert ID of xyz
  • Kibana gets upgraded and action and alert SO IDs are regenerated
  • Action runs, resolves action:abc to action:def, resolves alert:xyz to alert:123, action_task_params gets deleted
    Rule runs again and schedules an action with action_task_params with actionId: def and relatedSavedObject alert ID of 123

@chrisronline
Copy link
Contributor Author

I'm going to close this out, as the original research is invalid and need to be reworked. If this item is still applicable, we still reopen this ticket.

@kobelb kobelb added the needs-team Issues missing a team label label Jan 31, 2022
@botelastic botelastic bot removed the needs-team Issues missing a team label label Jan 31, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature:Actions/ConnectorTypes Issues related to specific Connector Types on the Actions Framework Feature:Actions Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams)
Projects
None yet
Development

No branches or pull requests

4 participants