Sharing behaviour
As per discussion at today's meeting, we decided to open a ticket to:
- Define what is/should be the sharing behavior on the platform
- Assert the tests we have are catching errors on this
- 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:
- The permissions are organized in levels (from the most private to the least):
Private
,Usable
,Shared
,Public
. - 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
andusable_by_team
) are ignored. - If the object is
Private
the lists are also ignored. Only the user, when logged in, can view and use the object in question. - If the object is
Usable
the lists forusable_by
andusable_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 theUsable
permission. Combinations of empty/having contents on any of those lists should be supported. - If the object is
Shared
, the lists ofshared_with
andshared_with_team
are looked up in the same fashion as forUsable
. The only exception here is that an object may be shared with some users/teams and usable other users/teams. So, if the object isShared
, authorization should look-up for viewing using theshared_with
andshared_with_team
attributes whereas for using only, with theusable_by
andusable_by_team
attributes. If these lists are empty, here is the expected behavior:- If
shared_with
andshared_with_team
are empty, then the object is shared with everyone. In this case, it should be madePublic
instead. I.e., there shouldn't be any case where an object has aShared
permission with emptyshared_with*
attributes. - 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 fromshared_with*
tousable_by*
?)
- If
- Sharing is an irreversible procedure (
+=
)
Impossible states:
- Object is
Shared
butshared_with*
attributes are empty - Object is
Private
butshared_with*
orusable_by*
attributes are non-empty - Object is
Public
butshared_with*
orusable_by*
attributes are non-empty - Object is
Usable
butshared_with*
attributes are non-empty
Requirements
From the above state, I tried to extract the requirements:
- Objects start their life time on the platform as
Private
. Only the author has view/use access on it. - 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). - It must be possible to make an object (algorithm, library, plotter and database)
Usable
to all users of the platform. - 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 itPublic
. - If an object is
Shared
, the author may optionally decide if it is stillUsable
by other users and teams. In this case, the platform should restrict the access accordingly. - Sharing shall be reversible, for as long as the object in question is not being used by anyone (
deletable()
answersTrue
). 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 isUsable
, it can always be madeShared
with the same or more users. If the object isShared
, it can always be made public. In summary, the currently implemented+=
rule applies.
Does that look reasonable?