377 UI display group and user info right next to each of the resource #392
Conversation
new methods for getting user and group authorization and roles
only return group roles for other method
should make dealing with permissions easier
codegen added
removing unused parts of new tab
modal does not work yet, file committed nothing added
not sure why no longer in a component
|
I have marked this ready for review. To test, create some groups. |
…t-to-each-of-the-resource
| dataset_id: str, | ||
| db: MongoClient = Depends(dependencies.get_db), | ||
| allow: bool = Depends(Authorization("editor")), | ||
| ): |
| @router.get( | ||
| "/datasets/{dataset_id}/groups_and_roles", response_model=List[GroupAndRole] | ||
| ) | ||
| async def get_dataset_groups_and_roles( |
| {"dataset_id": ObjectId(dataset_id)} | ||
| ): | ||
| current_authorization = AuthorizationOut.from_mongo(auth) | ||
| if len(current_authorization.group_ids) == 0: |
There was a problem hiding this comment.
This checks if there is no groups associated, but shouldn't it check if there is users associated with it? similar to the group one below?
|
|
||
|
|
||
| @router.get("/datasets/{dataset_id}/users_and_roles", response_model=List[UserAndRole]) | ||
| async def get_dataset_users_and_roles( |
There was a problem hiding this comment.
Is there a reason why the two methods need to be separate? Wouldn't it be easier to just have one method that returns all users and groups? Or are there situations where it makes sense for the client to only ask about one and not the other?
There was a problem hiding this comment.
That was part of my thinking. Users and Groups are also different in terms of their fields and how they are used for permissions, so I couldn't figure out 1 solution for both. For users you add their email to the dataset with a role, but for groups you add the actual uuid to the dataset with the role and not the group name. Using 1 object looked like it would require a bunch of extra checks for whether it's a group or a user, so I just did 2 separate object types with 2 endpoints.
| } | ||
|
|
||
| return ( | ||
| <TableContainer> |
There was a problem hiding this comment.
Can we add a card, or white background similar to what we have in other tabs to make those tables consistent?
…fo-right-next-to-each-of-the-resource' into 377-ui-display-group-and-user-info-right-next-to-each-of-the-resource
|
Check if the UI is filtering out users that are also in a group, if so can we display even if they are also in a group with same role? if it is done on API side, we can go ahead with this and create a separate issue to fix the API filter. Original comment: the one behavior that is in the "Sharing Tab" i will clarify is: |
…s an authorization separate from a group, then it will show here
I think I now have it where if a user has a separate role from their role as part of a group that shows under the Users and Roles table. I tested by creating a group and giving the group a 'Viewer' role, but then giving one of the users in the group the 'uploader' role. I don't see an entry for that user for 'viewer' but I do see it for 'uploader.' And if the role is the same it shows as well. So if a user has 'editor' role and a group has 'editor' role, the user shows up under Users and Roles. |
|
please resolve merge conflicts |
…t-to-each-of-the-resource # Conflicts: # backend/app/models/users.py # frontend/src/types/action.ts # frontend/src/types/data.ts
…t-to-each-of-the-resource
max-zilla
deleted the
377-ui-display-group-and-user-info-right-next-to-each-of-the-resource
branch
Making this a draft pull request so it's easier to get feedback.
Current problem is that backend methods seem to work, but I'm getting nothing on the front end.
Not sure why,will work on this.