Feedback required - Data-streaming-authorization edge case

[tcompa]

Requires: #3024 and #3025

---

1. Admin sets user1.project_dirs = ["/aaa", "/bbb"]
2. User1 creates a dataset with zarr_dir="/bbb/something"
3. Admin removes "/bbb" from user1.project_dirs.

Can user1 stream data from /bbb/something?

[jluethi]

Can user1 stream data from /bbb/something?

Let's go with no.

A bit of reasoning for our (@lorenzocerrone & my) decision:
When could this happen? Core scenario we thought through was a user that was in group b, but then changed their contract and is now in group c (in the same institution). This user still has access to Fractal server and their projects, thus still has zarr_dirs set. If the admin removes the project_dir /bbb and changes their computational profile, they should actually loose both processing as well as visualisation access.

Implication for transition: This means that we need to set relevant project_dirs for e.g. users at FMI to allow them streaming access to their prior zarr_dirs. Which anyway sounds meaningful to do

[tcompa]

Let's go with no.

This makes sense, and it would also be our first option (and thanks for the additional detail on when this could happen). However we need to iterate once more about expected behaviors.

---

When a project owner loses access to a project_dir (as you described) and then to some zarr_dir, it would be very weird that project guest actually has this access.

The specific example is as follows:

1. User1 creates a project and shares it with user2.
2. User1 has project_dirs=["/something", "/else"] and they create a dataset with zarr_dir="/else/where".
3. Now user2 can stream data from /else/where
4. Admin removes /else from the project_dirs of user1.
5. User1 has no access any more to /else/where
6. Does user2 have access to /else/where?

The currently-implemented answer is "yes", but the logical one is likely "no". If the owner doesn't have access any more, it would be very counterintuitive that a guest still has access.

---

The current data structure does not cover this feature. There is no attribute to say: this zarr directory should / should not be included.

Some options on how to proceed

1. The simple one is to make it impossible (in the API) to remove a project_dir if this operation would lead to an inconsistent state like the one mentioned above. This means that in the scenario described above (a user changing lab) most likely it would not be possible to remove the old-lab project_dir (unless the user first deletes all their datasets..).
2. We review other options to actually support users changing lab.

(cc @jluethi @lorenzocerrone)

[jluethi]

The currently-implemented answer is "yes", but the logical one is likely "no". If the owner doesn't have access any more, it would be very counterintuitive that a guest still has access.

Agreed. The logical answer would be no and the pattern above only fully makes sense if it's no for user 1 & user 2 after step 4 above.

Overall, this should be an edge case of course. I don't expect to see the scenario of removing items from project_dir regularly. And the "what happens when a user of a shared project switches labs" questions anyway is complicated: If user 2 stays in the same lab as user 1 was before, it would make some sense that they'd still have access (or have the project ownership "transferred" to them).

Given these complexities, I'm fine if we currently say removing project_dir is not possible in some cases (if there is a zarr dir that's in this project dir & not in other project dirs). We can have a broader conversation about user offboarding separately.