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] rename ServiceNow isLegacy property to usesTableApi (or similar) #114898

Closed
pmuellr opened this issue Oct 13, 2021 · 3 comments · Fixed by #115028
Closed

[actions] rename ServiceNow isLegacy property to usesTableApi (or similar) #114898

pmuellr opened this issue Oct 13, 2021 · 3 comments · Fixed by #115028
Labels
estimate:small Small Estimated Level of Effort Feature:Actions/ConnectorTypes Issues related to specific Connector Types on the Actions Framework Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams) technical debt Improvement of the software architecture and operational architecture

Comments

@pmuellr
Copy link
Member

pmuellr commented Oct 13, 2021

Mike Cote and I discussed some of the aspects of the isLegacy config property that got added to the ServiceNow connector in PR 105440. One of them is that isLegacy doesn't "scale well" over time, if we end up having to make some other change like this later, and have to come up with a isLegacy2 field as well. It's also not very descriptive of what it actually means.

We think rather than use a generic term like "legacy", we should probably be in the mode of describing the scenario more specifically instead. For instance, we could rename this field usesTableApi (the old API), with a default of false and the migration changing the old connectors to set this value to true. No changes to the value, just a change to the name. This makes it both "scale better" for other such properties we might need later, as well as being more descriptive in the code, as well as anyone looking at the raw connector data.

There don't seem to be a lot of references to the property in the actions and triggers_actions_ui plugins, so seems like something that would be straight-forward to fix.

This feels kinda low priority to me, and also that if we don't do it before 7.16, we probably don't want to do it at all, because it would then require ANOTHER migration, which seems like overkill. Perhaps it's just a "lesson learned" about a pattern we should avoid in the future ...

@pmuellr pmuellr added 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 Oct 13, 2021
@elasticmachine
Copy link
Contributor

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

@mikecote
Copy link
Contributor

cc @gmmorris as this should be triaged now as the issue is only valuable if done in 7.16.

@gmmorris
Copy link
Contributor

@mikecote - no need to block on me, feel free to triage this kind of thing yourself and simply let me know when you've done so.
Adding to ToDo 👍

@gmmorris gmmorris added technical debt Improvement of the software architecture and operational architecture estimate:small Small Estimated Level of Effort labels Oct 18, 2021
@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
estimate:small Small Estimated Level of Effort Feature:Actions/ConnectorTypes Issues related to specific Connector Types on the Actions Framework Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams) technical debt Improvement of the software architecture and operational architecture
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants