Permissions conflicts

[mjaquiery]

Is your feature request related to a problem? Please describe.
The relationships between resources mean that a component owned by Team A could be extended by Team B (e.g. Team A has defined the Cell Family for an LG HG2 cell, and Team B have used that family for a bunch of HG2 cells they're running tests on).

If Team A decides to change the visibility of the Cell Family, what should happen?

Describe the solution you'd like
There are a few options here:

• Forbid reducing the read access permissiveness on resources
  • This is quite restrictive, and may worry users, especially if they're concerned about making mistakes and leaking information. It would, however, be a good solution that supports 3rd-party crawling/dumping tools because we don't have to worry about public things being copied elsewhere.
• Forbid reducing the read access permissiveness on resources if they have any relatives that have more permissive read access
  • This highlights a conflict between parent and child resources permissions. Allowing parents to be only as restrictive as their most permissive child is a resonable solution, but unless child permissiveness is restricted by parent permissiveness, the parent's permissiveness will be altered by altering a child's. E.g. If I have a Cell Family that I allow any lab member to view, and another lab member creates a Cell instance using that family, if they decide that Cell should be publicly viewable by anyone, should that make my Cell Family public? Probably not, instead it should probably not be possible to make the Cell public unless the Cell Family is made public first.
• Create a public copy of the now-private resource
  • This seems prone to introducing mistakes and complications. Given the way e.g. Cell Families work, it is ontologically strange to have multiple definitions of the same Cell Family with different properties.
• Set the resource to private and still expose its properties through children/related resources
  • This seems odd from an access control standpoint - will it be clear to users that they're exposing information when they think they're working on a private resource?
• Set the resource to private and prevent read access via children/related resources
  • This is a bit of a 'let the chips fall where they may' approach, and risks removing necessary information from resources at the whim of the team that first deployed the resource parent.

Overall, there's no perfect solution here. I'm leaning towards the second one - forbidding closing off access where there are more permissive children available. And forbidding opening up children where the parent is not as open. We can implement programatic solutions to allow for setting cascading permissions if we adopt this solution.

Any thoughts @BradyPlanden @davidhowey @martinjrobins ?

[martinjrobins]

I would lean towards the second one as well. Is there the option of copying a cell family? If so then even if someone wanted to start adding private info to a public cell family they can just copy the public cell family to a private one and add the info there?

[mjaquiery]

Yeah, you can fork any resource you can view. Although whether it makes sense to do that for families is actually a tough question. It's mostly supposed to be a convenience for copying and editing rather than for actually having multiple copies of the metadata for the same entity.