Groups admin panel

[lucferbux]

Groups admin panel

Description

Added a new settings section to manage groups:

• Ability to control admin groups in the dashboard.
• Ability to control user groups in the dashbaord.
• Automatically detects a group selected is removed and notify the user.
• Adds the ability to support multi group selection.
• Grant by default permission for accessing settings panel to all the cluster admins

Kfdef

kind: KfDef
apiVersion: kfdef.apps.kubeflow.org/v1
metadata:
  name: opendatahub
  namespace: opendatahub
spec:
  applications:
    - kustomizeConfig:
        repoRef:
          name: manifests
          path: odh-common
      name: odh-common
    - kustomizeConfig:
        parameters:
          - name: s3_endpoint_url
            value: s3.odh.com
        repoRef:
          name: manifests
          path: jupyterhub/jupyterhub
      name: jupyterhub
    - kustomizeConfig:
        overlays:
          - additional
        repoRef:
          name: manifests
          path: jupyterhub/notebook-images
      name: notebook-images
    - kustomizeConfig:
        overlays:
          - authentication
        repoRef:
          name: manifests
          path: odh-dashboard
      name: odh-dashboard
  repos:
    - name: kf-manifests
      uri: >-
        https://github.com/opendatahub-io/manifests/tarball/v1.4.0-rc.2-openshift
    - name: manifests
      uri: 'https://github.com/lucferbux/odh-manifests/tarball/groups-panel'

How Has This Been Tested?

1. Upload this KfDef.
2. Disable the operator to be able to modify the configmaps without being reconciled.
3. Check the instructions in the docs about how the admin dashboard is enabled.
4. Start adding and deleting groups.
5. When having a group selected, if it's deleted in the cluster, it will trigger a new notification.

Merge criteria:

• The commits are squashed in a cohesive manner and have meaningful messages.
• Github Issue: Enable ODH Dashboard Admin & User groups #192
• KfDef added.
• Testing instructions have been added in the PR body (for PRs involving changes that are not immediately obvious).
• The developer has manually tested the changes and verified that the changes work.

[maroroman]

Looks good to me!

[bdattoma]

as per offline discussion, we should change the following behavior: Adds the ability to access settings panel to cluster admin and namespaced admins if the last group selected is removed by mistake. to Grant by default permission for accessing settings panel to all the cluster admins

[bdattoma]

as per offline discussion, we should change the following behavior: Adds the ability to access settings panel to cluster admin and namespaced admins if the last group selected is removed by mistake. to Grant by default permission for accessing settings panel to all the cluster admins

[lucferbux]

as per offline discussion, we should change the following behavior: Adds the ability to access settings panel to cluster admin and namespaced admins if the last group selected is removed by mistake. to Grant by default permission for accessing settings panel to all the cluster admins

Changed!

[dlabaj]

A few comments nothing that i would hold the PR up for we could fix them later.

[kywalker-rh]

We should change the design of this to use a drop down and chip groups similar to what is shown here. https://www.patternfly.org/v4/components/toolbar#with-custom-chip-group-content This way we won't have such a large drop down with items showing up. @kywalker-rh do you agree? This can be done in a future release. We could use a simple inline chip group below the drop down. https://www.patternfly.org/v4/components/chip-group

@dlabaj Agreed, the long dropdown looks awkward. FYI @vconzola

[vconzola]

@kywalker-rh @dlabaj I don't agree with using chip groups for something like this. By "large dropdown", do you mean that the width spans the entire page? If that's what's bothering you, can we just use the isWidthLimited property on the form?

[andrewballantyne]

This looks functionally sound. I'm going to approve and merge this.

My PR (#415) will need a rebase to rework the user related backend logic to what Lucas has done. So I need to merge this now to do that effort.

I'll be logging a follow up ticket to clean up the UI (and a couple of the backend concerns that are still around -- more style of code and maintainability of the React code). The effort should be non-user facing (ideally) and entirely so we can live with this code and have easier refactors in the future.

Thanks for all your work on this @lucferbux -- Again, very sorry it took so long to get this PR in. I was unaware of its importance to KFNBC release until yesterday.

/lgtm
/unhold

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: andrewballantyne, dlabaj, maroroman

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [andrewballantyne,dlabaj]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[andrewballantyne]

/lgtm

[andrewballantyne]

@kywalker-rh @dlabaj I don't agree with using chip groups for something like this. By "large dropdown", do you mean that the width spans the entire page? If that's what's bothering you, can we just use the isWidthLimited property on the form?

@vconzola @dlabaj @kywalker-rh I've added this to the UX meeting later today -- let us talk through it there.