Role requests UI #222
Role requests UI #222
Conversation
| )} | ||
| </TableCell> | ||
| <TableCell> | ||
| {row.resolver == null && row.status != 'PENDING' ? ( |
There was a problem hiding this comment.
nit - this ternary operator chain should be a function that returns a component instead of inline for readability and/or if someone wants to add a new condition but NAB
There was a problem hiding this comment.
Unless we're doing this multiple times on the page, I think an inline ternary is more readable instead of jumping back to read the function. Although, I'm onboard if we want to make multiple sub-component functions instead of a giant component return statement (which is what we normally do in Access and probably an antipatterm). Agree it's not a blocker, but definitely a nice-to-have refactor for readability which we can always do later.
| return params; | ||
| }); | ||
| setRowsPerPage(parseInt(event.target.value, 10)); | ||
| setPage(0); |
There was a problem hiding this comment.
I know the other search pages work similarly, but how would you feel about clearing all of the search params instead of setting the page explicitly to page 0? There's some inconsistent behavior I've noticed elsewhere due to this 🤷 NAB but was planning to make changes along this line at some later point
There was a problem hiding this comment.
I'll probably leave this for now since (while maybe not ideal, I have no idea what front end best practices are) it's consistent with most of the other pages
| {props.groupName}. | ||
| </Typography> | ||
| {props.rows.length == 0 ? ( | ||
| <Typography sx={{mt: 2}}> |
There was a problem hiding this comment.
This could probably be a little prettier. Maybe break up into multiple lines so the dialog isn't super wide? Also maybe insert a Divider or something to separate out the text from the headers?
There was a problem hiding this comment.
Better..? I made the dialog narrower and changed up the wording/colors/spacing a little but idk about how to make it pretty
| if blocked: | ||
| blocked_requests.append(req.id) | ||
|
|
||
| query = query.join(RoleRequest.requested_group).filter( |
There was a problem hiding this comment.
Does this work to combine this Access admin query with the query below or should this query be executed and stored as a list that gets appended to the output of the query below?
There was a problem hiding this comment.
It was actually right before I made any of the recent changes since the admin part of the if/else factored in owned groups and apps in addition to blocked requests. Removing the else just complicated achieving the same thing. Just reverted it.
eguerrant
force-pushed
the
role_requests_ui
branch
from
8c72de3 to
400cc14
Compare
Adding in Role Requests to the Access UI
In this PR, I:
General Workflow
If you own at least one role, a 'Create a request button' will be shown. You will have the option to choose for which of the roles you own you'd like to make a request, to which non-role group you'd like the role to be added to, membership/ownership, an amount of time for access, and the ability to provide a reason.
Owners or admins should be notified on role request creation.
Owners who are not blocked by group tag constraints can respond to the request. If the owner is blocked, a note will be shown.
If all group owners are blocked, Access admins will need to respond to the request. The request is added to admins' 'Assigned to me' list and a note is shown that all owners are blocked on the request page.
After a decision is made on the request, the requester is notified of the decision.
Regular role request read page:
Viewing role members who will be added if the request is approved:
Blocked owner role request read page:
Admin view all owners blocked request read page:
