Users & permissions - remaining frontend work

[pavish]

Fixes #2473
Fixes #2474
Fixes #2478
Fixes #2479
Fixes #2480

The following differs from the spec:

1. The figma design contains a dropdown to change access level of the user. The backend APIs do not allow updating this at the moment. As it stands, the manager will have to remove the current access of the user, and add again inorder to update it.
2. This requires product level confirmation - @kgodey
   • On the backend, if the user has 2 permission access levels, one on the database and one on the schema, the highest permission level will take precedence.
     • If user is viewer on db, and manager on schema, the user will have manager access on the schema.
     • If user is manager on db, and editor on schema, the user will have manager access on the schema.
   • The frontend behaviour is currently: access level on schema takes precedence over access level on the database. By this definition,
     • If user is viewer on db, and manager on schema, the user will have manager access on the schema.
     • If user is manager on db, and editor on schema, the user will have editor access on the schema.
   • This is because:
     • This is the simplest to implement and easier to convey to the user UX wise.
     • I didn't think this was a priority for the launch.
     • We can update this behaviour to be the same as that on the backend, once we come up with a better UX to convey this.
3. Improvised UX for the schema modal:

• 
• The schema modal shows the access level of the user at both db level and schema level.
• They cannot delete the db level access from this modal, so the delete button is disabled for such cases. They can delete the schema access level.

Checklist

• My pull request has a descriptive title (not a vague title like Update index.md).
• My pull request targets the master branch of the repository
• My commit messages follow best practices.
• My code follows the established code style of the repository.
• I added tests for the changes I made (if applicable).
• I added or updated documentation (if applicable).
• I tried running the project locally and verified that there are no
  visible errors.

Developer Certificate of Origin

Developer Certificate of Origin

Developer Certificate of Origin
Version 1.1

Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
1 Letterman Drive
Suite D4700
San Francisco, CA, 94129

Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.


Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I
    have the right to submit it under the open source license
    indicated in the file; or

(b) The contribution is based upon previous work that, to the best
    of my knowledge, is covered under an appropriate open source
    license and I have the right under that license to submit that
    work with modifications, whether created in whole or in part
    by me, under the same open source license (unless I am
    permitted to submit under a different license), as indicated
    in the file; or

(c) The contribution was provided directly to me by some other
    person who certified (a), (b) or (c) and I have not modified
    it.

(d) I understand and agree that this project and the contribution
    are public and that a record of the contribution (including all
    personal information I submit with it, including my sign-off) is
    maintained indefinitely and may be redistributed consistent with
    this project or the open source license(s) involved.

[pavish]

@kgodey I require your review on the UX and the behaviour as mentioned in the description. The UX is not good enough for my own expectations, but I don't see a better solution at the moment with the API constraints we currently have.

[kgodey]

• On the backend, if the user has 2 permission access levels, one on the database and one on the schema, the highest permission level will take precedence.

  • If user is viewer on db, and manager on schema, the user will have manager access on the schema.
  • If user is manager on db, and editor on schema, the user will have manager access on the schema.

• The frontend behaviour is currently: access level on schema takes precedence over access level on the database. By this definition,

  • If user is viewer on db, and manager on schema, the user will have manager access on the schema.
  • If user is manager on db, and editor on schema, the user will have editor access on the schema.

The frontend implementation of permission levels should be consistent with the backend. However, since this is erring on the side of decreased permissions, I'm fine with treating it as a non-launch blocking bug. Please open an issue to track fixing it.

Improvised UX for the schema modal:

We can fix this after launch if it will take time to implement, but here are the changes I'd make:

• We have one row per user in the current design, even if the user has multiple permissions. I'd change this to having one row per permission, even if that means multiple rows for each user.
• I would either use the pill design for all permission levels or not use the pill design at all. It looks weird to have them for some but not others.

[kgodey]

See comment in main thread.

[pavish]

@kgodey

The frontend implementation of permission levels should be consistent with the backend. However, since this is erring on the side of decreased permissions, I'm fine with treating it as a non-launch blocking bug. Please open an issue to track fixing it.

I agree. I'll open an issue to track it, however, I would like to discuss the behaviour of this at the product level. My suggestion is to go with the behaviour implemented on the frontend as of now, or come up with a better UX to let the user understand which of the roles take precedence. We can discuss this on the new issue.

We can fix this after launch if it will take time to implement, but here are the changes I'd make

This will not take a lot of time, I can make these changes today. Does the following UX look good? (I've not made these changes yet).

Notice that the second row appears disabled, inorder to indicate to the user that these permissions don't take any effect as they are superseded by the schema level permissions. I can add a tooltip when user hovers that row.

[kgodey]

My suggestion is to go with the behaviour implemented on the frontend as of now, or come up with a better UX to let the user understand which of the roles take precedence. We can discuss this on the new issue.

Let's discuss this on the new issue. I think we probably should come up with a better UX.

Does the following UX look good?

Yes, looks good.