Allow derivations of public entities belonging to different projects

[chr-pok]

Description:
Derivations are used to keep track of the relationship between circuits ("circuit_extraction" or "circuit_rewiring"). However, derivations are currently limited to entities within the same project context. In order to allow a user to derive new circuits from existing (public) ones in other projects, inter-project derivations should be made available.

Proposed behavior:

• The owner of the derived entity should be the owner of the derivation
• A derivation must be created within the same project context as the derived entity
• Inter-project derivations should be allowed
  • if the parent ("used") entity is private and the user has access to the project of the parent entity
  • If the parent ("used") entity is public, disregarding the project

Acceptance criteria:
Derivations from public entities can be created within different projects

[GianlucaFicarelli]

if the parent ("used") entity is private and the user has access to the project of the parent entity

1. The access control to the entities and their relationships is based on the project, so instead of considering the user, can this be changed to allow the derivation between private entities if and only if they both belong to the same project? (this restriction isn't needed if the parent is public)

2. If the parent (used) is private, is it allowed for the derived child (generated) to be either public or private?

[chr-pok]

1. The access control to the entities and their relationships is based on the project, so instead of considering the user, can this be changed to allow the derivation between private entities if and only if they both belong to the same project? (this restriction isn't needed if the parent is public)

Hmm, I believe this is a more general question about data sharing between projects. I would imagine that there are use cases where users build their own private circuits in one project, and they are used by the same or other users under a different project to extract private sub-circuits from it to run some experiments.

So I would say restricting it to the same project if private is still quite limiting. But if this is getting too complex, we can leave that discussion for later once we actually have such use cases.

2. If the parent (used) is private, is it allowed for the derived child (generated) to be either public or private?

Yes, I would say so, the derived entity can be either public or private. But I am not entirely sure about the implications of a public derived entity that would reference a private parent. But also here I would image that such use cases could arise if a derived entity is private at first, but will be made public at some later point. So I think this should be possible, but could potentially come later if complex.

[GianlucaFicarelli]

So I would say restricting it to the same project if private is still quite limiting. But if this is getting too complex, we can leave that discussion for later once we actually have such use cases.

In entities with direct references (for example MEModel -> CellMorphology), referencing private entities in different projects isn't possible (for example you cannot define a private MEModel in project1 linked to a private CellMorphology in project2), so it would be simpler to keep this restriction also for derivations, and eventually discuss it later if it needs to be relaxed.

Yes, I would say so, the derived entity can be either public or private. But I am not entirely sure about the implications of a public derived entity that would reference a private parent. But also here I would image that such use cases could arise if a derived entity is private at first, but will be made public at some later point.

I don't have a strong preference here, but if we don't allow adding a derivation from private entity to public entity, then we'll have to decide what to do with the used private entity if a generated private entity needs to be made public, as you mentioned.
We can allow it, but we'll need to ensure that:

• the endpoint /{entity_route}/{entity_id}/derived-from doesn't return private used ids when the user doesn't have permissions (this might need to add an additional condition in the query)
• the hierarchy endpoint filter out private parents when the user doesn't have permissions (this should be already work in this way, but better to verify)

[chr-pok]

In entities with direct references (for example MEModel -> CellMorphology), referencing private entities in different projects isn't possible (for example you cannot define a private MEModel in project1 linked to a private CellMorphology in project2), so it would be simpler to keep this restriction also for derivations, and eventually discuss it later if it needs to be relaxed.

Yes, makes sense to keep it consistent with the current behavior of other references, and come back to it later only in case it will be really needed.

I don't have a strong preference here, but if we don't allow adding a derivation from private entity to public entity, then we'll have to decide what to do with the used private entity if a generated private entity needs to be made public, as you mentioned.

Indeed, let's allow it then I would say, otherwise we would restrict users in their ability to make entities public.