Hey @dimitrie,
Can you please explain why for a project resource, the canRead and canWrite properties differ between the ones at the root of resource and the ones inside permissions prop? E.g. below, it seems that for the ones at the root, the owner has been dismissed in canRead…
Thanks,
Paul
Hello Paul, that’s a good question. Disclaimer: this is not the most elegant implementation, and will change in the future (don’t hold your breath though).
As you know, projects help set and track read/write permissions on the streams they contain. Nevertheless, projects themselves are a resource, so an end user can have read/write access on the project itself. Hence, there’s two separate fields tracking these relationships.
To clarify:
canRead & canWrite at the root of a project resource specify who can read or write that project. If a user needs write access to be able to add streams to that project.permissions.canRead & permissions.canWrite relate to the permissions users are granted on the streams in the project.I recently refurbed the way the web app shows things, it might clarify what’s going on:
Hope this helps.
Thanks, makes sense! At first I was confused, but now I understand that the permissions set on the project level overwrite permissions set on the stream level.
Yes, the actual server implementation details make sure that if someone is granted write permissions on a project, she or he will get write access to the streams too.
I remember thinking this through properly at the time, nevertheless it’s quite a bunch of convoluted code… See:
… important note: permissions can be granted through projects, as well as directly at a stream level, and a stream can be in multiple projects.
Hence roles can overlap, but speckle will not downgrade a user if he has a higher permission set from a different project, or set directly from a stream.
