[PLAT-191] resource level sharing

[pjain1]

Allows user to have access to only certain resources, for now limited to explore and canvas. Resources can be shared directly for a user or a usergroup.

Resource restriction works independently of the roles i.e. user or usergroup role can change but resource restrictions remains the same. This also allows to add user with a role with access to no resources at all. So this is possible

# Use --restrict-resources to not grant access to all resources
rill user add --project foo --email foo@example.com --role viewer --restrict-resources

# Then set the resources they should have access to
rill user set-resources --project foo --email foo@example.com --explore d1 --canvas d2 --canvas d3

# To clear restrictions
rill user set-resources --project foo --email foo@example.com --restrict-resources=false 

# To set restrictions on a usergroup
rill usergroup set-resources --group g1 --project foo --explore d1

# To see project level resource restrictions 
rill user show --email foo@example.com --project foo 

Similar cmds for usergroups.

Important Note

If user has any role on org level apart from guest then they automatically become part of system managed group named autogroup:members and thus resource restrictions won't apply unless one explicitly sets resources restrictions on autogroup:members group (which you should think twice before doing).

---

Existing APIs like AddProjectMemberUser and SetProjectMemberUserRole (and similar for usergroups) now accepts additional resource names and restrict-resources bool flag, if there are more than 0 resources in the call then restrict-resources is automatically set to true. The APIs works in PUT style i.e. with each call full list of resources should be provided and it just replaces the existing list, this means if resources are not set then resource list will be empty or if restrict resources flag is not set then essentially it give access to everything.

Permission Resolution

Resource restrictions only apply If all roles for the user/group have restrict resources set to true (AND of all flags); the effective resources will be union of resources from role and groups.

Backwards compatibility

Since the APIs now accept additional params, UI needs to populate them always by first fetching current resource list and restrict resource flag otherwise it may unintentionally give access to everything. If application changes cannot go in with these changes then we may change the flag to be optional and if not set then fetch current resources/flag and use those. Also restrict APIs being called from older versions of CLI.

Follow up (Component level sharing)

An interesting follow up could be have component level sharing so that specific components from the canvas can be shared, this will require refactoring component's ResolveTransitiveAccess and then at canvas level it will just merge component level transitive accesses.

Checklist:

• Covered by tests
• Ran it and it works as intended
• Reviewed the diff before requesting a review
• Checked for unhandled edge cases
• Linked the issues it closes
• Checked if the docs need to be updated. If so, create a separate Linear DOCS issue
• Intend to cherry-pick into the release branch
• I'm proud of this work!

[pjain1]

@begelundmuller Going through the comments wanted to discuss few high level things-

1. Merging project invites/setting roles with setting resources - I purposefully separated them, I don't remember exactly but it was adding too much logic in a single API. With separation its easy to just reject requests when there is pending invite with full role and then a resource level addition is done or ignore resource request when there is already a full role and there is not confusion around what role to set when resource sharing is done etc. So it just make things simpler I guess but I can club them together if you feel so.
2. Clearing of resources on setting full role like viewer and removing viewer role when all resources are removed - Are we not okay with these two behaviour?
   • Don't we want to clear all resources on setting any full role? Even a viewer role gives access to everything. Do we want to preserve shared resources list even when a full role is assigned to a user using some flag? But what is the use of this state? Do we expect that when the full role is removed we revert back to resource level access? that seems too much automatic things happening.
   • When all resources are removed we just remove entire viewer role so that they don't accidentally get access to everything.
   • It seems like from your comment above around --restrict-resources we would want a state where they have viewer role but access to no resources but what is the use of this state? And we would want to add resources in 2 steps - first add user with --restrict-resources and the use set-resources?
3. Incremental addition/removal of resources - We want to override resource list on each call?

[begelundmuller]

It would also be nice with a test case that adds/removes resource restrictions, and parses the generated JWT and checks if the security rules match the expecations

[begelundmuller]

Looks good for initial merge once the final comments have been addressed