Bug 1785487

Created attachment 1646725 [details]
RoleBindingsEmptyStateMessage

Hi yapei,
Are you saying other resources pages 'with normal user (w/o create privileges)' do not show the create buttons?  ...or do they all show up as disabled?
I'm logged in as kubeadmin, and I see the create buttons and text filter shown above the empty message on Image Streams, Machine Autoscalers, Groups, etc..  I'd image if I was logged in as a normal user the create buttons all show up as disabled - I'm having trouble adding/logging in as a normal user, so can't test atm.

It could be argued that we should not show the create buttons for users who do not have create privileges.

Thanks,
- Dave

Oh, I see the issue, when there are no projects the Getting Started message is displayed and the entire list component/page is disabled.  If there were role bindings, the role bindings table would be disabled as well instead of the empty msg.  

I think this is working as designed, if no projects show Getting Started and disable all else.  IMO it doesn't make sense to try to hide/show individual list page components (create button, text filter text box, etc..) when the Getting Started is shown.  It shows the user what they will unlock once they do the getting started step(s).

Do you aggree tony.wu?

Created attachment 1651796 [details]
DeploymentPageWhenEmptyProject

I attached some other resource page state when user don't have any project as comparison

This could be an oversight when working on supporting "non-privilege users" cases for the Admin Console. 
Since most of the other pages, in this case, would hide the "Create" call-to-action, agree we should follow that on the Role Binding page too for the consistency. Thanks.

The Create buttons for Deployments and Bindings are handled here: https://github.com/openshift/console/blob/master/frontend/public/components/factory/list-page.jsx#L249

Deployments uses a populated createAccessReview object:
{
  "model": {
    "label": "Deployment",
    "apiVersion": "v1",
    "apiGroup": "apps",
    "plural": "deployments",
    "abbr": "D",
    "namespaced": true,
    "propagationPolicy": "Foreground",
    "kind": "Deployment",
    "id": "deployment",
    "labelPlural": "Deployments"
  }
}
...which gets passed into <RequireCreatePermission ... /> and for non-admin users results in 'isAllowed' to be 'false', thus hiding the Create Deployments button. https://github.com/openshift/console/blob/master/frontend/public/components/utils/rbac.tsx#L138


For Bindings the createAccessReview object is null and the 'isAllowed' check is by-passed, thus the Create Bindings button is always displayed -albeit disabled when no projects and Getting Started is active.

This is why Create Deployments button is not shown, but the Create Bindings button is.   

Question is do we want to hide the Create buttons (+ text_filter, row filters, table, etc..?) when Getting Started is active?  I wouldn't think so because when Getting Started is active, the only option is for the user to Create Project and it disables the entire underlying resource page.  I imagine to show the user what they'll get access to, once they get past the Getting Started/Create Project steps.

I am thinking for RoleBinding page, change the Create button from:
"disabled when no projects and Getting Started is active"
to:
"hidden when no projects and Getting Started is active"

so that the experience between RoleBinding page and other pages are consistent (even though RoleBinding page is not using the same 'isAllowed' logic).

Note: Pipelinies -> Pipelines page also shows a disabled 'Create Pipeline' button when Getting Started is active.

normal user without any project logins to console and visit User Management -> Role Bindings page,  it will show 'No Role Bindings Found' and starting guide, no Create Bindings button 


Verified on 4.4.0-0.nightly-2020-01-18-223038

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:0581