Design forward: Sharing behavior

[jancborchardt]

Sharing improvements

As talked about with @DeepDiver1975 @butonic @MTRichards @karlitschek etc.

Precursors:

• Review new Share API, see Share API 2 #3969
• Improve the sharing dialog, see »Design forward: Sharing dialog« Design forward: Sharing dialog #3224
• Decide on how quota is calculated, see Shared Files filesize subtracted from quota + fix/patch #2796

Indicate owner and participants

Currently, you need to click on the dropdown to know who is the original owner of a file shared with you.

• Instead, this should be directly in the file list row, where the »Shared« icon is right now.
• In the future we can do that with user images or other autogenerated visual identifiers.

Get rid of the »Shared« folder – DONE!

Currently, there is an empty read-only »Shared« folder where files/folders shared with you will appear. This is very confusing.

• Instead, shares should by default directly go into the root folder.

Ability to move and rename shares freely - DONE

• As people arrange their files differently, one should be able to freely move and rename the root of the share. That is, folder and file name.

Notify recipients and prompt to accept/decline shares

Currently, shared files are immediately added to your account, which can fill up your storage. Then they get synced via the desktop client which in turn fills up your computer space.
We should have a mechanism to notify people of incoming shares so they can accept or decline them.
That should also be configurable for admins for cases where people need to be in shares.

[butonic]

@DeepDiver1975 technical notes:

• mount each share as a separate mount point. too expensive?
• moving over mount point boundaries (eg. moving a file from a shared folder to a non shared folder) causes copy by default. reason being that files contained in a shared folder also belong to that mount point.

[stephanarts]

@jancborchardt if shared files are only added to it's owner's quota, that solves the problem of filling up your storage aswell, doesn't it?

If I have 2 users with different quota's (10 and 1GB) and the user with a 10GB quota shares a 5GB file with the one having only a one GB quota will effectively block the second user from using ownCloud. This effectively prohibits a 'power-user' to collaborate with lesser mortals.

[mbremer]

In the current implementation all shared folders from different users are put in the same Shared folder. As a result, duplicate folder names will be mapped with a running number, e.g. pictures(2), while the original name is pictures.
I find this very confusing, because names should be the same as the original. One way to solve this is to have a shared folder for every user who shared stuff with you, e.g. Shared userA, Shared UserB. This would already solve the issue of identifying who's shared folder it is and you don't need a new column or identifier in your layout.

[jancborchardt]

@stephanarts the storage fill up problem still exists – for your computer, because currently a share is accepted and then synced automatically. For the storage and sharing stuff, see #2796 – I updated the original post above, thank you for the hint.

@mbremer we thought about that too but having folders named by the people who shared them with you actually makes little sense. The file or folder name itself is the most important, and who participates is a different matter. We shouldn’t enforce folder names like that.

[mbremer]

I am not sure if my point was understood. I only want the starting point of the share to have the user name, not the actual folders being shared. Attached is a similar concept from my laptop where in Finder (on the Mac) you have a list of shared folders from different users. Once you click on such a share you'll see the folder names just like the original.

[jancborchardt]

@mbremer I understood it. And thank you for the clarification but we aim to do it like I described above. Regarding desktop integration, shared folders should ideally be marked with a share icon badge similar to the sync status badges as talked about in owncloud/client#102

[schiessle]

Just a note regarding notifications about shares and the ability to accept/decline shares: We have to make sure that this also works for people who use the sync client only. It has to be possible to accept/decline shares both on the web interface and on the desktop client.

Although it is just a semi-official interface, but what about people who use their ownCloud only over a webdav mount, e.g. gnome online account? They will never be able to receive shares, right?

One more note regarding the time frame: Is it realistic to get this all into OC6? I would be already happy if OC6 comes with the new Share API and is at least as stable as OC5. Therefore I would vote for a stable and solid share API for OC6 and new share features for OC7.

[jancborchardt]

The notifications will come in via email then.

And I highly doubt this will be ready for ownCloud 6.

[DeepDiver1975]

@MTRichards does this approach match the product roadmap?

OC6 comes with the new Share API and is at least as stable as OC5

fullack

[DeepDiver1975]

@MTGap

Is the ShareAPI feature complete to fulfill the described behavior?
Please drop technical question/considerations - THX