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!