Allow other users to upload to shared albums

[vorlif]

I and some friends are happy to share our pictures about Lychee. When we're together we take all the photos and then it would be nice if we could put all our photos into one album. The problem with this is that users can only upload photos to their albums.

So it would be cool if other users could upload to shared albums.

[kamil4]

For now, the only workaround is to create a shared account and broadcast the password to your friends. Or, if it's only two people and one of them is a Lychee admin, that should also work, provided that the album belongs to the non-admin user.

We've also had a suggestion (I can't seem to find it in the issues right now, however) of a secret URL that could be used by everybody for uploads only.

Overall, I can't think of a technical reason why we couldn't implement album sharing in read-write mode (in addition to the current read-only mode). Maybe as part of the rework of the sharing dialog (https://github.com/LycheeOrg/Lychee-front/issues/104) which is currently pretty ugly...

[vorlif]

Thank you for your quick response and your ideas. :+1: We will try a shared account once. I would be happy if such a function would land one day in Lychee, but I am aware that you are working on this project in your spare time.

[haivala]

We need this!

[ildyria]

We need this!

We are also open to PR. :wink:

[kamil4]

I'm actually interested in working on this but I promised myself that I won't implement any new features until after the 4.0 release is out :smiley:.

[haivala]

Context:

1. We have folder/album made by admin which is for some party for example
2. Users should be able to create sub albums so that they can be credited and have their own license by album

Now we are using shared admin account.

[ildyria]

Sub-album per user in a album is too complicated (from an ownership management point of view).

[haivala]

I just meant that I want that everybody should have read and write privileges on shared folders. Isn't it the album creator who is the owner and sets the license? then shares that with other users and they can create sub-album and own that.

[ildyria]

The problem that goes then is the access rights... What if I create an album B inside another album A. I give read write access to B but not to A... This implies to manage annoying rules and slows down the server heavily. Then we also have a similar problem related to the diplay of thumbnails.

It may sound simple at first glance, but behind the scene it is pretty complex, we did lots of works to simplify this, adding another layer of complexity would not be really convenient. It its current state ownership is the ownership of the album. It is simpler. If you want to give credit, you can still use the descriptions.

[kamil4]

I'm with @ildyria on this one. I worry that mixed ownership of albums would quickly turn into a horrible mess. If album A of user A contains a subalbum B of user B, then is user A allowed to delete album A? It's their album after all but it now has contents that does not belong to them...

When we were working on this, we decided that even admin is not allowed to create such a situation. Any moves of photos or albums between users changes the ownership to the owner of the destination album. It makes things so much simpler...

Similarly, my instinct is that if we implement writable shared albums, any content created within a shared album by other users should belong to the owner of that album. Newly created subalbums will need to inherit the sharing properties of the parent album, of course.

[d7415]

Agreed. Though if we allow users with write access to create subalbums (or make that an option), they would still be able to store them in a tree as described.

[haivala]

I am a developer so I know how complexity works its mysterious ways :)

So basically first we need to explain everything that is happening so that we get clear picture what to do and agree on that. After that we can try to implement it if it's something we want to do. I think i'll sacrifice few brain cells for this on the weekend and try to invent the best solution.

[kamil4]

Sure. This is a volunteer-driven project and we welcome contributions from others.

A comprehensive proposal for mixed album ownership needs to cover, for instance:

• the ownership of photos uploaded to albums belonging to others, including who can make such photos public?
• the ownership of subalbums created inside albums belonging to others, including the defaults for sharing, and who can make such subalbums public?
• who can delete photos, subalbums, and subalbum contents belonging to others?
• can a user use the duplicate functionality on a photo not owned by them? Who owns the duplicate?
• what happens when sharing options are changed (e.g., an album is no longer shared with others, but it has contents owned by others)?

I'm sure the above list is incomplete but it's a start...

[haivala]

apparently the weekend is year later :D

What if these are the general rules:

• Owner owns only the folder and the pics in it and can change the all of the settings like it is now.
• Another user can create folder inside another users folder and owns only that folder ( this is the tree structure, more later)
• Only owner and admin can do everything
• Only admin can change folder ownership
• Duplication: can only happen in owned folder and if admin duplicates the owner stays the same (why would we even allow this?)
• There would not be the case where someone has pics owned by someone else in their folder.

Then there is the matter of tree structure:

• If user hides/deletes folder that has folder owned my someone else the tree structure is removed but the inside folder is still has the same settings and it is moved to the root of the tree (or one up?)

Basically we distinguish the tree settings from the album settings. This way we could have the move folder dialogue as it's own page with drag & drop functionality. Owner always has access to their folders from the albums marked under their name (like it is now) and that folder can be linked anywhere in the tree (by anyone if it is public?)

What do you think?

[ildyria]

apparently the weekend is year later :D

No worries, there is no hurry. I would say that most of the active developers are quite busy with their own life (kids popping up everywhere / PhD Thesis...)

What if these are the general rules:

• Owner owns only the folder and the pics in it and can change the all of the settings like it is now.

:+1:

• Another user can create folder inside another users folder and owns only that folder ( this is the tree structure, more later)

I am not in favor of mixed album ownership. This complexifies the back-end significantly, especially with respect to access control.

• Only owner and admin can do everything

As expected.

• Only admin can change folder ownership

That was indeed something I wanted to implement at some point. I would also give the possibility of a User A to transfer ownership to another User B (e.g. as a repo on Github).

• Duplication: can only happen in owned folder and if admin duplicates the owner stays the same (why would we even allow this?)

Folder duplication by itself should be a separate issue, but I think it should be added. :+1: Duplication by another user should not be allowed IMHO unless if proper access rights (see below).

• There would not be the case where someone has pics owned by someone else in their folder.

:+1: That is something we currently ensure.

Then there is the matter of tree structure:

• If user hides/deletes folder that has folder owned my someone else the tree structure is removed but the inside folder is still has the same settings and it is moved to the root of the tree (or one up?)

Assume:

• User A owns album A,
• User B owns album B, album B is in album A,
• User A owns album C, album C is in album B.

What happens if User A deletes album A ?

• albums B goes to root level. we are pretty clear on that one, though having albums poping up at the root is not necessarily a great idea, especially given that it immediately changes the visible structure).

  For example, I use a lot `hidden-visible` combination. I create a album H with hidden visibility, and inside of it I have a bunch of visible albums V1 V2 V3, that way when I share H, people can see the multiple V1 V2 V3, and if they press `ESC` by mistake they can still go back without having to find the link again.

• what about album C? Does it stays "alive" in album B or is it deleted as per user A wishes?

Basically we distinguish the tree settings from the album settings. This way we could have the move folder dialogue as it's own page with drag & drop functionality. Owner always has access to their folders from the albums marked under their name (like it is now) and that folder can be linked anywhere in the tree (by anyone if it is public?)

What do you think?

---

TL;DR:

I am not in favor of separating the tree structure from the album structure. (sorry) Aside from adding complexity, it also makes Lychee less understandable as this creates "exceptions" rules.

• If you say all the sub albums & pictures inside an album A are owned by the owner of album A, it makes it simple to understand.
• If you start saying "pictures in album A are owned by user A, but sub album B is in album of User A and is owned by user B, also pictures in album B are owned by user B..."

I am however in favor of adding the possibility to make albums writable, currently they are only readable, I would not be against adding a write parameter. :)

PS: adding drag&drop would be great, even just for pictures, but this should probably just be a front-end PR and a separate issue. :+1:

[haivala]

I think that the separating the tree structure from the ownership of the albums removes complexity. We wouldn't need to think who owns what. The tree structure is just a way to build the view for the albums. User should be able to make their own trees too like you described in your hidden-visible combo.

Tree structure by design also gives answer to the remove of branch problem and there is libraries that you can use for that. It is really easy to use too. For example: http://mikehillyer.com/articles/managing-hierarchical-data-in-mysql/ or/and https://github.com/Atlantic18/DoctrineExtensions/blob/v2.4.x/doc/tree.md

[haivala]

So my point is that it would not create "exception" rules as we would not need to think how you described it in your details.

I played with this: https://codepen.io/phphe/pen/KRapQm and came up with this: The tree would have predefined roots: the users and the "service root". user would be able to do any kind of structure under their tree and have any kind of options in the albums. the "service root" would be the now called public view where any user could drag&drop any users public folders even in so many places as they want. We would not need show other users tree to the user that is logged in... And btw deleting a branch would not be a problem as we could just disallow it in frontend when node has child albums.

I just think you should evaluate this again without thinking how things work now..

[haivala]

@ildyria have you thought about this?

[haivala]

Just wondering. What is situation with this?

[ildyria]

The situation is that we are missing time & contributors. 😐

Le 5 mai 2021 à 09:28, à 09:28, "Harri Häivälä" @.***> a écrit:

Just wondering. What is situation with this?

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/LycheeOrg/Lychee/issues/383#issuecomment-832474573

[esenjin]

We would also be very interested in such an option, we use Lychee in a collaborative framework in our association and currently only the president can put images in all folders, which is really inconvenient, it forces him to be constantly disturbed. Being able to give different members access to certain albums would be a significant addition for our organization =)

[Sp4rkR4t]

I just set up lychee on a home server after testing a few options and this is the only feature I'd really like to see implimented.

[ceepeebee213]

Guessing this isn't going to happen? :)

[qwerty287]

It is, but wie have other priorities right now. Feel free to send a PR :)

[haivala]

This has been closed. Is there some hoops I need to go through so that I can have albums I described in this issue? I have installed 5.0 but have not played around with the new system yet.

[pichouk]

On 5.0.2 I created a new user test and an album test, and then shared the album with this test user. When the user open the album, I just have an HTTP 403 error.

[ildyria]

Can you open a new issue on that @pichouk ?