As per discussion at today's meeting, we decided to open a ticket to:

1. Define what is/should be the sharing behavior on the platform
2. Assert the tests we have are catching errors on this
3. See if there would be any way we could simplify the logic as to make the check faster and more programatically evident

Current situation

As indicated by our discussion, here is what I understood:

1. The permissions are organized in levels (from the most private to the least): Private, Usable, Shared, Public.
2. If the object is Public, then any user can view the object. Logged in users can use them in experiments. The contents of the 4 lists of users and teams (shared_with, shared_with_team, usable_by and usable_by_team) are ignored.
3. If the object is Private the lists are also ignored. Only the user, when logged in, can view and use the object in question.
4. If the object is Usable the lists for usable_by and usable_by_team are looked up. If they are empty, then the object is usable by all users and all teams available in the platform. If the lists are not empty, they implement a restriction saying "only" those have the Usable permission. Combinations of empty/having contents on any of those lists should be supported.
5. If the object is Shared, the lists of shared_with and shared_with_team are looked up in the same fashion as for Usable. The only exception here is that an object may be shared with some users/teams and usable other users/teams. So, if the object is Shared, authorization should look-up for viewing using the shared_with and shared_with_team attributes whereas for using only, with the usable_by and usable_by_team attributes. If these lists are empty, here is the expected behavior:
   1. If shared_with and shared_with_team are empty, then the object is shared with everyone. In this case, it should be made Public instead. I.e., there shouldn't be any case where an object has a Shared permission with empty shared_with* attributes.
   2. If usable_by* attributes are empty, then everybody on the platform will be able to use the contribution. (Comment: so, basically, if we want to share an algorithm we have to copy-n-paste the user list from shared_with* to usable_by*?)
6. Sharing is an irreversible procedure (+=)

Impossible states:

1. Object is Shared but shared_with* attributes are empty
2. Object is Private but shared_with* or usable_by* attributes are non-empty
3. Object is Public but shared_with* or usable_by* attributes are non-empty
4. Object is Usable but shared_with* attributes are non-empty

Requirements

From the above state, I tried to extract the requirements:

1. Objects start their life time on the platform as Private. Only the author has view/use access on it.
2. It must be possible to make an object (algorithm, library, plotter and database) Usable, meaning users/teams in a list can use it (not view it).
3. It must be possible to make an object (algorithm, library, plotter and database) Usable to all users of the platform.
4. It must be possible to make an object Shared, meaning users/teams in a list can use and view the said object. Note that "sharing" with all is the same as making it Public.
5. If an object is Shared, the author may optionally decide if it is still Usable by other users and teams. In this case, the platform should restrict the access accordingly.
6. Sharing shall be reversible, for as long as the object in question is not being used by anyone (deletable() answers True). This is, effectively, the same as forking, deleting the existing object and renaming the new object to the old name, which should certainly be possible for as long as nobody is using it. If the object is being used, then the sharing permissions cannot be lowered, only raised. I.e., if the object is Usable, it can always be made Shared with the same or more users. If the object is Shared, it can always be made public. In summary, the currently implemented += rule applies.

Does that look reasonable?