Rishab Jain

@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...

(As discussed with @rahmatrhd ) Guardian CLI commands will also have to be updated in release 2

@ravisuhag @AkarshSatija @bsushmith @singhvikash11 @rahmatrhd **Problem** Github differs from the other providers we already have in guardian currently. According to the current flow in guardian, whenever the approver approves the...

@rahmatrhd yes, was thinking to add that. Should we rename `pending` to `invite_sent` or `invite_pending` to sound more precise? And if the invite isn't accepted, we might introduce another state...

Github/Gitlab (and other public SAAS based platforms) do not expose the user email to public by default. Currently we were only using the user email to grant/revoke access to the...

**Problem** 1. @rahmatrhd and I tried generating the group access token for provider credentials in our personal gitlab groups/repo, but we couldn't find an UI based approach to do that...

Can we make a cron job/API to regularly fetch resources first rather than ignoring resources not synced with Guardian.? That would increase the scope for drift management as well but...

1. I don't think having different type of accounts would make any difference, initially I wanted to keep both `user` and `serviceAccounts` (as you mentioned `bot accounts` may also be...

For the 4th point mentioned by @bsushmith and @rahmatrhd , I was thinking instead of creating multiple appeals for the same user, can we instead update the duration of the...

During our initial discussion, on the same lines as point 1 which @ravisuhag mentioned, @rahmatrhd suggested adding this **team/group** entity in Shield instead of Guardian, if we are to proceed...