Ravi Suhag
Ravi Suhag
This is already handled in a separate PR.
Draft PR which addresses this issues. https://github.com/odpf/guardian/pull/167
@rahmatrhd I think option 2 is better to start with. we can have an API to import access which can be triggered manually and a corresponding cli command e.g.`guardian provider...
@rahmatrhd As part of import access, we should ignore the access of resources that are not registered in Guardian. The drift of resources can be handled separately.
In addition to this, at provider level provider will provide a method that takes resources as input and import access for the provided resources.
One way to identify the sensitivity of data could be with labels on datasets. Few more questions, that insights can provide answers to: 1. How many times a resource is...
@singhvikash11 Can you document how it will change the contract of appeal? Are you proposing that `create_appeal_for_other_user_check` this step will only be needed when admins want to disable the appeal...
@rahmatrhd Will this config be a root level config at the policy? Can you give an example of how the policy would look like this with the flag? @singhvikash11 Can...
Yes, Creator i think should always be the person who created appeal and created_by id should be of appeal creator. We can think of a different of capturing on whose...
Update: Creator will own the entire appeal lifecycle and appeal will not show in account_id's appeals. Later Guardian will provide a context of resources which user have access to provide...