Align wrong/missing permissions messages on Management UI

[markov00]

Each page in Management UI has a different way to say that the logged in user doesn't have the right privileges to modify/see that page.

From a better usability, I think we should provide a unique way to inform the user about that, using an aligned view to describe the problem and give a possible solution.

We are also calling the same thing in various ways: permission denied, access denied
missing privileges, missing sufficient privileges, unauthorized.

The following list shows some screenshot taken from demo.elastic.co management page for a guest user:

users:

roles:

index management:

index lifecycle policies:

upgrade assistant:

Spaces:

Logstash pipeline:

Beats:

Some page use the EuiEmptyPrompt that seems a good way to implement this unauthorized message prompt.

@elastic/eui-design what do you think about?

[elasticmachine]

Pinging @elastic/kibana-design

[elasticmachine]

Pinging @elastic/kibana-docs

[ryankeairns]

Adding the docs team to assist with sorting out the preferred terminology.

[gjones]

Oh interesting, in Cloud we're added a few similar pages for the RBAC project, I wonder if we can agree on a standard and create a component for it, similar to euiTable empty state. cc @pugnascotia @webfella

[pugnascotia]

Agreed, maybe this is at least worth documenting as a pattern in EUI. Cloud is mostly disabling buttons with a tooltip that explains why.

[cchaos]

For Kibana specifically, we agree that we need a standard pattern for whole plugins/sections being disabled because of permissions (though it also seems like something that should maybe be completely hidden from that user -- no item in the management side nav).

One of the quirks we're dealing with right now is the mix of Angular code still floating in those pages. For instance, I believe the Roles listing page is still Angular (which is why that callout looks different from all the rest). So in order to make them all the same, we'll also need to make sure all the pages are React.

[snide]

Let's start with a guideline in EUI. End of day a lot of this stuff happens because the teams that are working on them are different and they're just making their own calls. The screens above represent 4 floating teams (security, elastic ui, ingest, ops).

People have been asking for more guidelines. Seems as good a one to start as any.

[schersh]

@gchaps and I are happy to help with the wording in these messages, once we know which components we're going to recommend in the guidelines.