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

[Alerting] attempted editing of preconfigured action causes walkback in browser #78892

Closed
pmuellr opened this issue Sep 30, 2020 · 2 comments · Fixed by #78994
Closed

[Alerting] attempted editing of preconfigured action causes walkback in browser #78892

pmuellr opened this issue Sep 30, 2020 · 2 comments · Fixed by #78994
Assignees
Labels
Feature:Alerting Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams)

Comments

@pmuellr
Copy link
Member

pmuellr commented Sep 30, 2020

From a recent master:

Create a pre-configured action that has config properties, like email. Here's an example you can put in config/kibana.dev.yml for a repro in a dev environment:

xpack.actions.preconfigured:
  maildev-no-auth:
    name: 'email: maildev no auth'
    actionTypeId: '.email'
    config:
      from: 'me@example.com'
      host: 'localhost'
      port: '1025'

Start up Kibana, navigate to the connectors list, click on that pre-configured action. That normally takes you to the action "editor", but instead will render an empty block where the editor would been, with the following walkbacks in the browser:

walkbacks in the browser console:
Uncaught TypeError: Cannot read property 'from' of undefined
    at Object.validateConnector (email.tsx:32)
    at ConnectorEditFlyout (connector_edit_flyout.tsx:74)
    at renderWithHooks (react-dom.development.js:16260)
    at mountIndeterminateComponent (react-dom.development.js:18794)
    at beginWork$1 (react-dom.development.js:20162)
    at HTMLUnknownElement.callCallback (react-dom.development.js:336)
    at Object.invokeGuardedCallbackDev (react-dom.development.js:385)
    at invokeGuardedCallback (react-dom.development.js:440)
    at beginWork$$1 (react-dom.development.js:25780)
    at performUnitOfWork (react-dom.development.js:24698)

react-dom.development.js:21843 The above error occurred in the <ConnectorEditFlyout> component:
    in ConnectorEditFlyout (created by ActionsConnectorsList)
    in ActionsConnectorsContextProvider (created by ActionsConnectorsList)
    in section (created by ActionsConnectorsList)
    in ActionsConnectorsList (created by component)
    in HealthCheck (created by component)
    in component (created by Context.Consumer)
    in Route (created by TriggersActionsUIHome)
    in Switch (created by TriggersActionsUIHome)
    in div (created by EuiPanel)
    in EuiPanel (created by EuiPageContent)
    in EuiPageContent (created by TriggersActionsUIHome)
    in main (created by EuiPageBody)
    in EuiPageBody (created by TriggersActionsUIHome)
    in TriggersActionsUIHome
    in Suspense
    in Unknown (created by Context.Consumer)
    in Route (created by AppWithoutRouter)
    in Switch (created by AppWithoutRouter)
    in AppWithoutRouter (created by App)
    in AppContextProvider (created by App)
    in Router (created by App)
    in App
    in EuiContext (created by I18nContext)
    in PseudoLocaleWrapper (created by I18nProvider)
    in IntlProvider (created by I18nProvider)
    in I18nProvider (created by I18nContext)
    in I18nContext

I think I tracked this back to the fact that preconfigured actions have their config stripped out when returned from the getAll() actionClient method. Here's the relevant issue #63392 and pr #64266.

Kinda wondering if we want to reconsider the decision to not return the config of preconfigured actions, to prevent these kind of errors in the future. Or perhaps try to "fix" this via typescript typing somehow, or more elaborate testing.

@pmuellr pmuellr added Feature:Alerting Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams) labels Sep 30, 2020
@elasticmachine
Copy link
Contributor

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

@pmuellr
Copy link
Member Author

pmuellr commented Sep 30, 2020

I feel like we should probably be doing e2e testing on both a dynamically created connector and a pre-configured connector - seems like most tests just use a dynamically created connector.

Email is a good one as it has config, secrets, and params. There's a special value of the config param service we can use that provides a loop-back response, without having to have a real email server running (which we don't have right now); relevant code here:

if (service === JSON_TRANSPORT_SERVICE) {
transportConfig.jsonTransport = true;
delete transportConfig.auth;
} else if (service != null) {

@gmmorris gmmorris self-assigned this Sep 30, 2020
@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:Alerting Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams)
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants