-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
[Uptime] Disable 'Create Rule' button when user doesn't have uptime write permissions [#118404] #120379
Conversation
5e5dd16
to
8e574b8
Compare
Pinging @elastic/uptime (Team:uptime) |
8e574b8
to
8eae631
Compare
There was a problem hiding this 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.') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.') |
There was a problem hiding this comment.
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.', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
findByText('Creating alerts in this application requires write access to Uptime') | |
findByText('You need read-write access to Uptime to create rules.') |
There was a problem hiding this comment.
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') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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`] = ` |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
a039275
to
1d9e159
Compare
…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.
1d9e159
to
d7272ff
Compare
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. |
abe5784
to
a0b4853
Compare
@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:
You can see these problems on the GIF below. @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 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. ResolutionAs 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. |
a0b4853
to
d7272ff
Compare
There was a problem hiding this 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; |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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?
There was a problem hiding this 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:
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.
@elasticmachine merge upstream |
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:
Considering the above, the separate issue #121098 has been created. |
💚 Build Succeeded
Metrics [docs]Async chunks
History
To update your PR or re-run it, just comment with: |
…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>
💚 Backport successful
This backport PR will be merged automatically after passing CI. |
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. |
…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>
…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>
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:
Both changes above can be seen in the gifs below (in the same order):
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
All
permissions to use Machine Learning capabilitiesviewer
roleTest Case 2: Top Menu - Alert Enabled
Test Case 3: Monitor View - Alert Disabled
All
permissions to use Machine Learning capabilitiesviewer
roleTest Case 4: Monitor View - Alert Enabled
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.