Kibana: Confusing UX when editing Email connector with secrets

[mikecote]

When I edit Email connector that has secrets, it's not clear UX that username / password is required for enter in the edit form. This could cause confusion, because user can change the rest of the data and click save, but won't be actually saved. User won't get any notification that username / password fields is required for entering, because they was entered previously. User should have a possibility to remove credentials directly with some UI option

cc @bmcconaghy

In the screenshot below, this is the edit form after creating an email connector with a username / password. As you can see the values are blank on edit and I can actually save the connector with blank values (erasing the existing ones).

[elasticmachine]

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

[YulNaumenko]

The UX problem which we have for Email connector is kind of tricky by the reason that we are not able just to make this secret fields required, because user and password is optional configuration options.
But for the Email connectors where this credentials was defined we should ask user to enter this as a required to avoid the security vulnerability issues on Edit.
My proposal here will be to extend Email configuration with the property hasAuth and based on having this value as true make entering user and password required and disable a save connector button till both will be filled by the user. I also think that we should have an option to remove credentials here (Like button remove auth which set hasAuth to false). For the connectors with hasAuth false, we can provide a button on the Edit flyout "Change authentication" and by click on this to display the form for entering new user password. I think in this flow users won't be confused with always visible empty fields and available Save. (cc @mdefazio , @mikecote )

[YulNaumenko]

Update on the previous proposal: what about extending get API with some additional field or endpoint which return the list of secrets field names which was previously filled for this connector? In this case we may solve some generic case (not Email specific only for the user/password). In UI we can parse the fields and based on the specific UI requirement make some changes like proposed above with adding buttons or placeholders info.

[pmuellr]

That sounds like an interesting approach ^^^ - returning an indication for secret fields if they had previously been set.

Note that email user/pass is an interesting case to think about, as those fields are optional - we added that because the cloud email proxy specifically requires you to NOT user a user/pass! But in theory, for any secret property that can be "null", the UI will get trickier as it's valid to switch from using a secret value to not using it, and vice versa.

But I'm guessing, in general, something like this will work in practice.

How might we do this? Maybe the GET request on an action would return a new property secretFieldsSet: string[], which would include the secret fields that had actually been set? Those might end up being paths, in the case of a secret field in a nested object property, not simple property names, but I'm guessing today they would all be simple property names. We might want to restrict secrets to only allowing simple properties - or even only allowing string properties - which could be useful in other contexts as well.

[mdefazio]

Here's my thought on this. Is it odd to not have credentials shown by default (wouldn't that be the more common scenario?) But this is close to what Yuliia had originally, but instead having that add/remove toggle always available in the UI as a reminder that credentials were required/not required when connector was created (or last modified).

[pmuellr]

I _think_ these "optional" secrets are really just for the email connector, right now. And there's only one odd case where you would not want to set them AFAIK - when using the cloud email proxy for ESS cloud deployments. And there's lots of gotchas when using that proxy anyway - it's going to be the very rare case when someone needs to not use the secrets. Most of the time, they will need to enter credentials for their email server here.

So the default, at least in this case, is that we should assume they're required, unless the user clicks a toggle that says "do not send credentials". Basically, the opposite of the way it's shown above.

At least for email. If we have other or future optional secrets, I think we'll have to determine which way to go on the "use" / "don't use" secrets toggle, assuming we do them the same way.

Other than that, 👍.

[mikecote]

I'm experimenting with the PR and the "Do not send credentials" label felt a bit weird from my perspective. I wonder if we keep the label "Add credentials" but default to selected instead? Probably worth @gchaps' input.

Screenshot:

[gchaps]

I prefer a positive label (add) over a negative label (don't). Credentials is a little vague. How about:

Add username and password

[gmmorris]

I might be missing something, but it feels like we are aren't addressing one of the problems with the existing UX.

As we still don't indicate to the user that values have been set before, they'll continue to think their values were deleted.
I can see users opening the edit dialogue to investigate why their connector isn't working and as the fields are empty - it'll continue to confuse them.

[YulNaumenko]

I've updated the issue description where exact describing the problem which current PR https://github.com/elastic/kibana/pull/78235 solve.

I can see users opening the edit dialogue to investigate why their connector isn't working and as the fields are empty - it'll continue to confuse them.

For the generic empty secrets fields problem, I've opened this issue https://github.com/elastic/kibana/issues/78476. Currently we have the same behavior for all action types with secrets - this fields are required if they was entered and we show validation errors on focus left event and Save button for the form is disabled.

[pmuellr]

@gchaps: I prefer a positive label (add) over a negative label (don't). Credentials is a little vague. How about:
Add username and password

In almost all cases, users will need to use a user/pass. There are a very small number of cases where users would NOT want to use a user/pass. Very small. Hence the "negative" label.

If we make this a positive level, I suspect a lot of customers won't enter it, and then the action will fail, and then we'll be at the mercy of the email provider to provide a good message the customer can understand.

[mikecote]

If we make this a positive level, I suspect a lot of customers won't enter it, and then the action will fail, and then we'll be at the mercy of the email provider to provide a good message the customer can understand.

If we go the positive label approach, wouldn't it be selected by default? That way the validation will make the fields required unless the user deselects the switch to not provide user/pass.

[YulNaumenko]

We set default for Add username and password as true, so users should be OK to have it turned on. You can try and test it :)