[APM] Show missing permissions message to the user on the Services overview

[formgeist]

Summary

We want to display a message to the user if Kibana Security is enabled and the user does not have the right permissions through their user role to view APM data indices.

Currently, we show a toast to the user when trying to load any view in APM if they do not have the right permissions, but we want to enhance that experience by showing them a message when they land on the first page (the Services overview) in APM UI.

The message at the very least includes a link to the APM Server docs on how to manage the roles and permissions. https://www.elastic.co/guide/en/apm/server/current/feature-roles.html

Design solution

We want to strip away a lot of the core UI components to create a roadblock screen that shows an EuiEmptyPrompt for those users who don't have the proper permissions to access APM at this time.

Keeping the page title and the Setup instructions link in the top header, but otherwise stripped for UI controls (time picker, query bar etc. and navigation).

Question is whether we would setup another route for this page, so it reads not "Services" in the breadcrumb, but rather "No permissions to access APM" or the similar. Not part of this iteration.

We want to offer the user a way to access the Services overview anyways, even if it gives them an empty state and the toast notification with the error when trying to access to the apm-* index added below the main CTA to the documentation. Consider this an escape hatch for users who might have a very specific roles setup.

Implementation notes

We can use the kibana_write_user in the apm-integration-testing setup to test https://apm.elstc.co/ the scenario where a user with no permissions to read the apm-* indices.

[elasticmachine]

Pinging @elastic/apm-ui (Team:apm)

[formgeist]

@elastic/apm-ui Thoughts on the above implementation? This replaces the existing solution where we display a toast, but rather display an empty prompt that gives more description to the issue and a way for users to read our documentation on permissions in Kibana.

[sorenlouv]

I think this looks great 👍

This replaces the existing solution where we display a toast

The description says "Currently we show a toast when trying to load any view in APM, which can be kept as is". Just want to be clear what we are aiming for.

If possible I think we should only show the toast as a fallback for the UI's where we don't have a dedicated error message. So in this case we should not show the toast.

[formgeist]

If possible I think we should only show the toast as a fallback for the UI's where we don't have a dedicated error message. So in this case we should not show the toast.

I can see how it's not clear; do you agree with that we intend to redirect the user back to this page if they i.e. get linked to the Transaction detail page without the appropiate permissions, which means this page is our default page to display? That means not displaying the toast in almost all cases AFAIK?

[sorenlouv]

do you agree with that we intend to redirect the user back to this page if they i.e. get linked to the Transaction detail page without the appropiate permissions

I hadn't actually thought about that. tbh I think that's outside the scope of this. For us to be able to link back to the service overview we need to do a permission check. Having these checks everywhere is not necessarily trivial, and I think it's better to start with the obvious landing page and make that work well.

The toast should still show up for general errors (service unavailable, server errors etc).

[formgeist]

I hadn't actually thought about that. tbh I think that's outside the scope of this. For us to be able to link back to the service overview we need to do a permission check. Having these checks everywhere is not necessarily trivial, and I think it's better to start with the obvious landing page and make that work well.

That's fair, no need to expand the scope of this.

The toast should still show up for general errors (service unavailable, server errors etc).

Ah, I think I misunderstood you in the first comment. I agree, toasts are still available for those other errors. Only meant it replaces the no permissions toast.

[formgeist]

I've updated the description to reflect this ^

[sorenlouv]

Since #51824 we now have dedicated users. I think when creating issues about permissions we should refer to these users.

In this case kibana_write_user does not have access to apm* and will not see any services, and should see a permission message instead. OTOH apm_write_user should be able to see all services.

[formgeist]

@sqren Added a note in the description that will carry over to implementation.

[formgeist]

@sqren I've moved this over to the implementation board, but it still sits in the Inbox. Not sure if we're still planning on getting this in for the next release or not.

[formgeist]

@cauemarcondes I've updated the description with a revised screen mock up for the added option to skip the permission roadblock to access the Services overview anyways.

[dgieselaar]

Can we track stuff here as well? like, clicking through and then whether or not the UI successfully loads anyway?

[cauemarcondes]

@cauemarcondes I've updated the description with a revised screen mock up for the added option to skip the permission roadblock to access the Services overview anyways.

@formgeist a few questions:

• Are we going to show this page only when the user navigates to the services page /services?
• What would happen when a user manually opens another page /services/SERVICE_NAME/transactions?
• With the escape link, a user will be able to open the apm page, what should we do when the user refreshes the page? Or when he clicks on the APM icon again?

[formgeist]

Thanks @cauemarcondes - here's my comments to your questions;

Are we going to show this page only when the user navigates to the services page /services?
What would happen when a user manually opens another page /services/SERVICE_NAME/transactions?

Preferably, we should redirect to this page roadblock if they try and access any page in APM. Generally, the user won't be able to access anything because they don't have the right permissions. We could opt to show a toast in those other scenarios, but I'd prefer to redirect to this, because that's just a single point of entry/roadblock for those users without the appropriate permissions.

With the escape link, a user will be able to open the apm page, what should we do when the user refreshes the page? Or when he clicks on the APM icon again?

Same roadblock. The link is just an escape hatch from that initial roadblock. I know that might seem harsh, but tbh they have seemingly no permissions to access APM data, so I'd rather roadblock than to save their "escape hatch" in session. @graphaelli thoughts on this?