-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Decouple access management from appeal #246
Comments
@rahmatrhd does the mean of |
@mabdh yes, that's the case for permanent access |
@bsushmith and I were having some discussions on invite based providers, suppose a user requesting for a resource didn’t accept the invite within the given the time(24 hours), should we make him create the appeal on guardian again? In that case the managers/resource owners will have to approve the appeal again for the same user. We were thinking if there’s a possibility to ensure that if the approvers have already approved the user's appeal, and the invite has expired, can we keep a boolean flag ( |
@bsushmith @Chief-Rishab I was thinking that guardian can have a job that periodically checks the invitation status to the provider and set the access status to |
in order to rollout this Release 1
Release 2
In between those two releases we can update the client (frontend) to use @mabdh @Chief-Rishab @ravisuhag @bsushmith @singhvikash11 please have a look and let me know if there's something I missed |
Why can't this be part of Release 1 ? |
@mabdh the releases I mentioned are specific for guardian (backend), updating the client going to be a separate task. But still, release1, update client, and release2 had to be done sequentially as each depends on the prior task |
@rahmatrhd based on what you mention, updated client should be part of release 2 then? |
@mabdh the client (frontend) now is managed in different project/repo anyway, so the requirement for guardian is only to have two separate releases/versions with requirements I mentioned above. This strategy is basically to give the client chance to update to the new version without breaking/having downtime during the backend is using release1, and release2 is basically to remove the deprecated/unused features. |
Oh I see got it, by client, I thought it is guardian cli. |
(As discussed with @rahmatrhd ) Guardian CLI commands will also have to be updated in release 2 |
Summary
Currently,
appeal
acts as the information holder for approval flow and user access. We can decouple those responsibilities by creating a new entity calledaccess
that manages user access and its lifecycle.Changes:
1. Process
appeal
is approved, guardian will create anaccess
entry representing the current user access to the resourceaccess
instead ofappeal
access
(if exists) and create a new one.2. Entity
Appeal:
Access:
3. Lifecycle
Appeal:
Access:
The text was updated successfully, but these errors were encountered: