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

[Uptime] Disable 'Create Rule' button when user doesn't have uptime write permissions [#118404] #120379

Conversation

lucasfcosta
Copy link
Contributor

@lucasfcosta lucasfcosta commented Dec 3, 2021

Summary

This PR closes #118404.

Before this PR, users would be able to open the flyout to create an alert and would end-up seeing an error toast when they tried to save it. This flyout could be opened both from within the the top menu, and the monitor view itself, in the popover for when users have enabled anomaly detection.

This PR adds commits to:

  • Disable the create alert button in the menu on the top when the user doesn't have permissions to write to Uptime. It will also display a helpful tooltip.
  • Disable the create alert button within the monitor view itself, in the popover for when users have enabled anomaly detection. This disabled button will contain a tooltip too.

Both changes above can be seen in the gifs below (in the same order):

tooltip-top

tooltip-anomaly

Furthermore, after this PR users who don't have access to uptime will not see the flyover for creating alerts popup automatically because they can't use it anyway.

How to this PR:

Test Case 1: Top Menu - Alert Disabled

  1. Create a role which has All permissions to use Machine Learning capabilities
  2. Create a new user and assign it the role from step (1) and the viewer role
  3. Login with the user from step (2) and ensure that you cannot use the top menu to create an alert (the button should be disabled) and that a tooltip appears.

Test Case 2: Top Menu - Alert Enabled

  1. Create a monitor and make sure it has run
  2. As a user with write access to Uptime, try use the button on the top right corner to create an alert. The button should be enabled and the alert creation should succeed.

Test Case 3: Monitor View - Alert Disabled

  1. Create a monitor and make sure it has run
  2. Create a role which has All permissions to use Machine Learning capabilities
  3. Create a new user and assign it the role from step (2) and the viewer role
  4. Login with the user from step (2) and access the details page for the monitor from step (1)
  5. Try to create a new anomaly detection rule and ensure the alert flyout does not pop automatically.
  6. Ensure that when clicking the anomaly detection button you cannot create an alert (the button should be disabled) and that a tooltip appears.

Test Case 4: Monitor View - Alert Enabled

  1. Create a monitor and make sure it has run
  2. As a user with write access to Uptime, try to create a new anomaly detection rule and ensure the alert flyout does pop automatically.
  3. Ensure that the button to create an alert in the "Anomaly detection" is enabled and that you can create an alert through it

Checklist

Delete any items that are not applicable to this PR.

For maintainers

Release note

Disables the button to create alerts in Uptime when users do not have permissions to do so.

@lucasfcosta lucasfcosta force-pushed the disable-alerts-creation-button-without-uptime-write branch from 5e5dd16 to 8e574b8 Compare December 6, 2021 15:37
@lucasfcosta lucasfcosta added auto-backport Deprecated - use backport:version if exact versions are needed release_note:fix Team:Uptime - DEPRECATED Synthetics & RUM sub-team of Application Observability v8.0.0 v8.1.0 labels Dec 6, 2021
@lucasfcosta lucasfcosta marked this pull request as ready for review December 6, 2021 15:57
@lucasfcosta lucasfcosta requested a review from a team as a code owner December 6, 2021 15:57
@elasticmachine
Copy link
Contributor

Pinging @elastic/uptime (Team:uptime)

@lucasfcosta lucasfcosta force-pushed the disable-alerts-creation-button-without-uptime-write branch from 8e574b8 to 8eae631 Compare December 6, 2021 17:41
Copy link

@EamonnTP EamonnTP left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good. Just a couple of minor copy suggestions.

userEvent.hover(getByText(labels.ENABLE_ANOMALY_ALERT));

expect(
await findByText('You need write access to Uptime to create anomaly alerts.')
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
await findByText('You need write access to Uptime to create anomaly alerts.')
await findByText('You need read-write access to Uptime to create anomaly rules.')

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmmm, actually having thought again about this:

I was thinking that perhaps the change from alerts to rules would actually have a different meaning from what the button does.

In that PR we're disabling the ability to create alerts themselves, as the rule is already created when users get to see that tooltip.

I will keep "alerts" as we discussed on Slack, thank you @EamonnTP!

export const ENABLE_ANOMALY_NO_PERMISSIONS_TOOLTIP = i18n.translate(
'xpack.uptime.ml.enableAnomalyDetectionPanel.noPermissionsTooltip',
{
defaultMessage: 'You need write access to Uptime to create anomaly alerts.',
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
defaultMessage: 'You need write access to Uptime to create anomaly alerts.',
defaultMessage: 'You need read-write access to Uptime to create anomaly rules.',

userEvent.click(getByText('Alerts and rules'));
userEvent.hover(getByText(ToggleFlyoutTranslations.openAlertContextPanelLabel));
await expect(() =>
findByText('Creating alerts in this application requires write access to Uptime')
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
findByText('Creating alerts in this application requires write access to Uptime')
findByText('You need read-write access to Uptime to create rules.')

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've updated this to:

You need read-write access to Uptime to create alerts in this app.

Otherwise users could be confused as to why they'd need write access to Uptime to create alerts in general. I thought it would be good to be specific and clear that this only applies for alerts in this application.

userEvent.click(getByText('Alerts and rules'));
userEvent.hover(getByText(ToggleFlyoutTranslations.openAlertContextPanelLabel));
expect(
await findByText('Creating alerts in this application requires write access to Uptime')
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
await findByText('Creating alerts in this application requires write access to Uptime')
await findByText('You need read-write access to Uptime to create rules.')

const noWritePermissionsTooltipContent = i18n.translate(
'xpack.uptime.alertDropdown.noWritePermissions',
{
defaultMessage: 'Creating alerts in this application requires write access to Uptime',
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
defaultMessage: 'Creating alerts in this application requires write access to Uptime',
defaultMessage: 'You need read-write access to Uptime to create rules.',

@@ -1,5 +1,128 @@
// Jest Snapshot v1, https://goo.gl/fbAQLP

exports[`Manage ML Job rendering renders without errors 1`] = `
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we please avoid snapshot tests, we discourage these in uptime and prefer using RTL.

Copy link
Contributor Author

@lucasfcosta lucasfcosta Dec 7, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great shout, these were actually not supposed to be here as I deleted the old snapshot tests and started using RTL exactly because I also wanted to avoid snapshot tests. I'll clean up.

@lucasfcosta lucasfcosta force-pushed the disable-alerts-creation-button-without-uptime-write branch from a039275 to 1d9e159 Compare December 7, 2021 11:50
…rite permissions [elastic#118404]

Before this commit, users would be able to open the flyout to create an
alert and would end-up seeing an error toast when they tried to save it.

This commit will now disable the create alert button when the user
doesn't have permissions to write to Uptime. It will also display a
helpful tooltip.
…ime [elastic#118404]

This commit causes users not to be able to use the "Enable Anomaly
Alert" button within the popover in the monitors screen. That button
will now be disabled and contain an informative tooltip whenever users
don't have permissions to write to Uptime.

We've chosen to take this approach so that we don't have to modify the
component which deals with the alert creation, which belongs to another
team and that we plan on eventually replacing. Furthermore, this pattern
is already used in the logs app.
@lucasfcosta lucasfcosta force-pushed the disable-alerts-creation-button-without-uptime-write branch from 1d9e159 to d7272ff Compare December 7, 2021 14:25
@liciavale
Copy link
Contributor

liciavale commented Dec 7, 2021

Is there any doc we could link? Like a Read more or something to explain how to get access to Uptime or what to do in case I want to enable this? The tooltip is useful to give context but I wonder if we should link it to somewhere else to explain what to do next.

@lucasfcosta lucasfcosta force-pushed the disable-alerts-creation-button-without-uptime-write branch from abe5784 to a0b4853 Compare December 7, 2021 16:52
@lucasfcosta
Copy link
Contributor Author

lucasfcosta commented Dec 7, 2021

@liciavale That could be a great idea, and I have attempted to add a link to the tooltip themselves. That attempt led me to discover why we don't do this anywhere else:

  1. You can't click on the links in them because as soon as you hover out of the element the tooltip disappear
  2. The link contrast requires style and doesn't work out of the box, so we need to style it with a ghost colour.

You can see these problems on the GIF below.

tooltips-problem-links

@liciavale, considering the above (only number 1 actually, given 2 is easy to do), are you okay not to have the link there?

An alternative would be to use a popover instead and make it pop using an event listener for the hover event.

However, considering we'll also have to have hoverable tooltips in the recorder (and that tooltips should be hoverable anyway as per this link), IMO it would be much cleaner an DRYer to make tooltips support hovering rather than using popovers as tooltips.


Resolution

As discussed with @liciavale, I've opened an issue in the EUI repo here: elastic/eui#5453 and for now we won't add the link to the tooltip.

Copy link
Contributor

@liciavale liciavale left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm!

dispatch(setAlertFlyoutType(CLIENT_ALERT_TYPES.DURATION_ANOMALY));
dispatch(setAlertFlyoutVisible(true));

const hasUptimeWrite = core.services.application?.capabilities.uptime?.save ?? false;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i am not sure why we are checking uptime.save capability, shouldn't we check if user has alerting save capability?

alerting:save

Copy link
Contributor Author

@lucasfcosta lucasfcosta Dec 9, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not really, unfortunately, that's not the capability used to save alerts. I did discuss this with Justin and he mentioned that we actually rely on save, not on alerting:save, which is, by the way, always true, even when users have only read permissions.

Given save permission is what is actually used, I was thinking that investigating why we don't use alerting:save could be a separate issue, what do you think?

Copy link
Contributor

@justinkambic justinkambic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM - I took the time to repro this on main as well, seems to be working as designed.

Note:

Not sure if we consider this within the scope of these changes, but seems related. I can still open up the "add connector" dialogue from the settings page:

image

I'm not able to create anything once I'm in there, but we should simply disable the link as we have done for the rest of the elements on the page.

@lucasfcosta
Copy link
Contributor Author

@elasticmachine merge upstream

@lucasfcosta
Copy link
Contributor Author

Having spoken about this PR with @justinkambic on Slack we agreed that the "create connector" button within the "settings" page will be out of scope for this PR because:

  • It deals with a different permission (actions and connectors, as seen below), not with the write permission for Uptime.
    Screenshot 2021-12-13 at 15 28 16
  • It would require a different copy, and thus a whole new review from design/docs/product, which would elongate the cycle time for this PR for longer than we need it given it's an unrelated permission that has a different problem.

Considering the above, the separate issue #121098 has been created.

@kibana-ci
Copy link
Collaborator

💚 Build Succeeded

Metrics [docs]

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id before after diff
uptime 683.3KB 684.1KB +839.0B

History

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

@lucasfcosta lucasfcosta merged commit afefefa into elastic:main Dec 14, 2021
@lucasfcosta lucasfcosta deleted the disable-alerts-creation-button-without-uptime-write branch December 14, 2021 09:25
kibanamachine added a commit to kibanamachine/kibana that referenced this pull request Dec 14, 2021
…rite permissions [elastic#118404] (elastic#120379)

* [Uptime] Disable 'Create Rule' button when user doesn't have uptime write permissions [elastic#118404]

Before this commit, users would be able to open the flyout to create an
alert and would end-up seeing an error toast when they tried to save it.

This commit will now disable the create alert button when the user
doesn't have permissions to write to Uptime. It will also display a
helpful tooltip.

* [Uptime] Disable "Enable Anomaly Alert" when users can't write to uptime [elastic#118404]

This commit causes users not to be able to use the "Enable Anomaly
Alert" button within the popover in the monitors screen. That button
will now be disabled and contain an informative tooltip whenever users
don't have permissions to write to Uptime.

We've chosen to take this approach so that we don't have to modify the
component which deals with the alert creation, which belongs to another
team and that we plan on eventually replacing. Furthermore, this pattern
is already used in the logs app.

Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
@kibanamachine
Copy link
Contributor

💚 Backport successful

Status Branch Result
8.0

This backport PR will be merged automatically after passing CI.

@kibanamachine
Copy link
Contributor

Looks like this PR has a backport PR but it still hasn't been merged. Please merge it ASAP to keep the branches relatively in sync.

@kibanamachine kibanamachine added backport missing Added to PRs automatically when the are determined to be missing a backport. and removed backport missing Added to PRs automatically when the are determined to be missing a backport. labels Dec 16, 2021
kibanamachine added a commit that referenced this pull request Dec 16, 2021
…time write permissions [#118404] (#120379) (#121163)

* [Uptime] Disable 'Create Rule' button when user doesn't have uptime write permissions [#118404] (#120379)

* [Uptime] Disable 'Create Rule' button when user doesn't have uptime write permissions [#118404]

Before this commit, users would be able to open the flyout to create an
alert and would end-up seeing an error toast when they tried to save it.

This commit will now disable the create alert button when the user
doesn't have permissions to write to Uptime. It will also display a
helpful tooltip.

* [Uptime] Disable "Enable Anomaly Alert" when users can't write to uptime [#118404]

This commit causes users not to be able to use the "Enable Anomaly
Alert" button within the popover in the monitors screen. That button
will now be disabled and contain an informative tooltip whenever users
don't have permissions to write to Uptime.

We've chosen to take this approach so that we don't have to modify the
component which deals with the alert creation, which belongs to another
team and that we plan on eventually replacing. Furthermore, this pattern
is already used in the logs app.

Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>

* add missing useKibana hook to ML Flyout Container for detecting uptime write permissions

Co-authored-by: Lucas F. da Costa <lucas@lucasfcosta.com>
Co-authored-by: Lucas Fernandes da Costa <lucas.costa@elastic.co>
TinLe pushed a commit to TinLe/kibana that referenced this pull request Dec 22, 2021
…rite permissions [elastic#118404] (elastic#120379)

* [Uptime] Disable 'Create Rule' button when user doesn't have uptime write permissions [elastic#118404]

Before this commit, users would be able to open the flyout to create an
alert and would end-up seeing an error toast when they tried to save it.

This commit will now disable the create alert button when the user
doesn't have permissions to write to Uptime. It will also display a
helpful tooltip.

* [Uptime] Disable "Enable Anomaly Alert" when users can't write to uptime [elastic#118404]

This commit causes users not to be able to use the "Enable Anomaly
Alert" button within the popover in the monitors screen. That button
will now be disabled and contain an informative tooltip whenever users
don't have permissions to write to Uptime.

We've chosen to take this approach so that we don't have to modify the
component which deals with the alert creation, which belongs to another
team and that we plan on eventually replacing. Furthermore, this pattern
is already used in the logs app.

Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
auto-backport Deprecated - use backport:version if exact versions are needed release_note:fix Team:Uptime - DEPRECATED Synthetics & RUM sub-team of Application Observability v8.0.0 v8.1.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Uptime] Users can't save ML Job alerts and see error when they don't have write access to uptime
8 participants