Lychee
Lychee copied to clipboard
[Change Request] New Approach to Public Photos (Change When a Photo is Considered Public)
This change request addresses the aspect when a photo is considered to be publicly accessible. This question has recently be raised in the discussion of #1141. While both topics influence each other, IMHO, the should be discussed separately. Also there are a lot of related issues on this topic #1148, #1039, #941, #1135, #1084. So, I think it is time to discuss this topic fundamentally.
Current Situation
At the moment both albums and photos have a flag is_public
. A photo is publicly accessible if its parent album is public or if the photo is public. If only the photo is public, but not its parent album, then a user needs a direct link in order to access the photo. (A photo is public, but hidden.) In particular, the "OR" approach makes it impossible to have only some private photos in an otherwise public album.
Proposed Change
The condition should be changed into an AND, i.e. a photo should only be publicly accessible if the photo itself is public and if the parent album is public (more precisely, the whole path from the root the photo must be public). This would a) enable to have some private photos within a public album (see #1039, #1135) and b) follow the approach how nearly every file system works.
To easily make a whole album including its content publicly available, the dialog to change the public settings of an album should provide an option to recursively apply any changed setting to its children. Optimally, there would even be two check boxes: the first allows to apply the changes to direct children, the second checkbox becomes available if the first one has already been checked and allows to apply the changes to recursive children (see #1084).
Clarification
The proposed change only addresses the aspect of accessibility, not visibility or browsablility. E.g. a public photo in a public album might still be invisible and excluded from search results, if the attribute requires direct link
is enabled.
Long-Term Future
The proposed change may only be a first step to enable a more sophisticated rights management for albums and photos in the long run. While I have a concrete "subject-operation-object" model in the back of my mind which also would allow have mixed ownership albums as well as a fairly good idea how I would implement it, I don't want to overload this thread with too many ideas at once.
I think we first need a very clear definition of the following terms:
-
public
-
visible
-
hidden
-
browsable
-
accessible
-
require direct link
I know that it is tied to #1055 and no matter how embarrassing it is, I am not sure exactly I understand the model accessibility anymore (as there are some overlapping terms).
I would also suggest to add such page to the FAQ or digging deeper section of the documentation.
more precisely, the whole path from the root the photo must be public
I'm also confused about that condition.
think we first need a very clear definition of the following terms:
No problem.
-
Photos have the following relevant, basic attributes (i.e. they are directly stored in the DB)
-
album: ?Album
-
is_public: boolean
-
owner: User
-
-
Albums have the following basic attributes
-
is_public: boolean
-
requires_link: boolean
-
owner: User
-
shared_with: Collection<User>
-
password: ?string
-
Note, that none of these basic attributes alone suffices to immediately determine what a user "experiences" (in the broader sense). Also note, that we are only talking about "read" access here and that we do not support sub-trees of albums with mixed ownership along the path. I know that you know that, but in case somebody else reads this, too, it is worth to be mentioned.
Now, the definition of the terms which directly influence the user experience. (These terms are completely documented in AlbumAuthorisationProvider
and PhotoAuthorisationProvider
).
-
Album-related Terms
-
Visibility: An album is called visible if the current user is allowed to note an album's existence, i.e. see the album (itself) within a listing or similar. An album is visible if any of the following conditions hold (OR-clause):
- the user is an admin
- the user is the owner of the album
- the album is shared with the user and the album does not require a direct link
- the album is public and the album does not require a direct link
-
Accessibility: An album is called accessible if the current user is allowed to browse into it, i.e. if the current user may open the album and see its content. An album is accessible if any of the following conditions hold (OR-clause):
- the user is an admin
- the user is the owner of the album
- the album is shared with the user
- the album is public AND no password is set
- the album is public AND the correct password has been entered
-
Browseability: This is a recursive definition and requires a "helper" definition first. An album is called not blocked, if the user can reach the album from its direct parent. In order to be not blocked, the album must be visible and accessible at the same time, i.e. the user must be able to see the album and must have the privilege to enter it. The combination of both sets of conditions yields that an album is not blocked, if any of the following conditions hold (OR-clause):
- the user is the admin, or
- the user is the owner, or
- the album does not require a direct link and is shared with the user, or
- the album does not require a direct link, is public and has no password set, or
- the album does not require a direct link, is public and the correct password has been entered
An album is called browsable, if
- there is a path from the origin to the album, and
- no blocked albums on the path from the origin to the album exist.
-
-
Photo-related Terms
-
Visibility: A photo is called visible if the current user is allowed to see the photo. A photo is visible if any of the following conditions hold (OR-clause):
- the user is the admin
- the user is the owner of the photo
- the photo is part of an album which the user is allowed to access
- the photo is public
-
Searchability: A photo is called searchable if the current user may find the photo as a result of a search. A photo is searchable if any of the following conditions hold (OR-clause):
- the user is the owner of the photo
- the photo is part of an album which the user is allowed to browse
- the photo is public and searching through public photos is enabled by configuration
-
Visibility: A photo is called visible if the current user is allowed to see the photo. A photo is visible if any of the following conditions hold (OR-clause):
The term "hidden" should be avoided. If it is still used somewhere in the source code, then this is a left over. Previously, "hidden" was used with two different meanings: as an antonym for "visible" and as a synonym for requires_direct_link
. This was very confusing, because a photo may be hidden (in the sense of being invisible) due to various reasons and being hidden (in the sense that it requires a direct link) was only one of those reasons.
Back to my original post
The problem is that a photo already becomes visible if its album is accessible. This makes it impossible to have some "private" photos in an otherwise accessible album.
My proposal
I extend my initial proposal. I suggest to
- also make it possible to share photos with users, i.e. add
shared_with: Collection<User>
to photos and - change the definition of visibility of a photo as follows: A photo is called visible if any of the following conditions hold (OR-clause):
- the user is the admin
- the user is the owner of the photo
- the photo is part of an album which the user is allowed to access AND the photo is public or shared with the user
Rationale:
I would like to extend shared_with
to.l individual photos and interpret the attribute is_public
as a wildcard for the shared_with
attribute. I.e. a public photo/album behaves as if it was shared with any existing or presumably added user in the future as well as the unauthenticated user. Here and below, when I say "a photo is shared with a user" this may also covers the case that a photo is public and therewith shared with anybody.
If we require that a user must have the right to access the album AND the photo must be shared with the user, we enable that subsets of photos in an album are not automatically visible by everyone who may access the album. Instead, each photo must be explicitly shared explicitly. This resembles the way how nearly any filesystem works and is what user probably expect.
Note: This does not rule out to have an UX feature which allows to (re-) configure the sharing settings recursively.
@nagmat84 what is the status on this one?
That is not an issue in the sense of a bug, if you mean this. This is meant as a start for discussion into what direction Lychee should develop. I believe it is general knowledge that Lychee is missing a lot with respect to sharing and user permissions: a) there are no groups, b) it is impossible to have private albums/photos inside an otherwise public album (a much requested feature) and c) a change of sharing settings is not propagated recursively through the album hierarchy. We only had a related discussion just recently in the lobby.
This issue was meant to consolidate all these change requests, bugs, etc. in one issue for discussion, because we need a holistic approach on that. In particular, we need to decide what the overall approach should look like. When we have decided that I am actually willing to do the implementation part.
Until now the typical approach was that someone implemented a change, then submitted a PR and hence the PR dictated what the change would look like. The only options was either to accept it (incl. bug fixing, of course) or reject it and therewith destroying a lot of work. This time I would like to do it the other way around. This means we should first discuss the way into which Lychee should develop and agree an an architecture and then implement it. This is way this issue is called "Change request" and not "Bug".
@kamil4, @d7415 In particular, I am interested into your opinions. So maybe everybody should read the initial post again and then we discuss the ideas.
With the current change of access rights applied to album. I believe this is no longer relevant.