How to handle lists with Casl ?

[jlefebvre1997]

Hello everyone,

My use case is pretty simple : I have 2 entities, User and Workspace, and a page to list all the workspaces. A user can be an admin of a workspace.

Currently I have defined an action List to determine if a user can list all the workspaces. Is there a way I can define a rule that would allow a user to list only the workspaces for which he's an admin ? Or should I go with an additional action like ListOwn and use different queries for the different use cases ?

Thanks for your help 🙏

[stalniy]

How is the user and workspace linked on data layer?

[jlefebvre1997]

It's a ManyToMany, a user can belong to multiple workspaces, a workspace can contain multiple users

[stalniy]

I wanted to have a particular example of eventual aggregated root.

If eventually you get currently logged in user as:

const user = {
  id: ...,
  permissions: [
    { workspaceId: ...., role: 'admin' },
    { workspaceId: ..., role: 'manager' }
  ]
}

Then you can define this permissions:

can('List', 'Workspace', { id: { $in: user.permissions.map(p => p.workspaceId) } }); // read

// assume if user is an admin of Workspace then he can update it, then do this:
const updatableWorkspaceIds = user.permissions.filter(p => p.role === 'admin').map(p => p.workspaceId);
if (updatableWorkspaceIds.length) can('Update', 'Workspace', { id: { $in: updatableWorkspaceIds  } })

or you can have permissions on Workspace side and have workspace to be like this:

const workspace = {
  id: ...,
  users: [
     { userId: ..., role: 'admin' },
     { userId: , role: 'manager' }
  ]
}

then you can define permissions like this:

can('List', 'Workspace', { 
  users: { $elemMatch: { userId: loggedInUser.id  } }
})

additionally you can restrict on role:

can('List', 'Workspace', { 
  users: { $elemMatch: { userId: loggedInUser.id, role: 'admin'  } }
});

// or 

can('Update', 'Workspace', { 
  users: { $elemMatch: { userId: loggedInUser.id, role: 'admin'  } }
});

In general, you should not have actions like List and ListOwn. Instead you should have single "read" action because it's about reading data.

Very likely user can do something else in workspaces where he is an admin, like updating workspace. So, you already have this "natural" action which represents "list own" which is actually list all that can be updated/changed/delete/whatever

[jlefebvre1997]

Oh ok that makes sense ! I haven't thought about Update vs Read this way, it's clearer now thank you ! 🙏

[jlefebvre1997]

I wonder about a use case I came across : What if some roles can see the entire list of Workspaces, but some roles can only see the workspaces they're in ?
I'll expand a bit more on my use case :

I have an entity called Organization, which contains Users and Workspaces. Users have Roles, and it's as you described, a User can have multiple Roles on multiples entities, so for example, a User's Roles can look like this :

[
    { 'resourceId': 'workspace1', role: 'admin' },
    { 'resourceId': 'workspace2', role: 'user' }
]

However, some Users have upper Roles, in which case they don't have direct permissions on the "sub resource". For example, a User can be an admin of an Organization, in which case he should be able to update all the Workpaces inside of this Organization, but without having an explicit permission on said Workspaces. So in this case, I can't just filter like you showed. Can it be handled with Casl alone ?

At the moment I made a simple check like

if (user.isOrganizationAdmin) // return all workspaces
else // return only updatable workspaces

But I'm not 100% satisfied with this, even though it works.

I also thought of adding a role for this user on each created workspace, but I'm not 100% satisified with that either...

[stalniy]

You can use another field on workspaces, organizationId

can(read, Workspace, { organizationId:  loggedInUser.organizationId }):
can(read, Workspace, { permissions: { $elemMatch: … } })