Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for room shares #10255

Merged
merged 16 commits into from
Aug 9, 2018
Merged

Add support for room shares #10255

merged 16 commits into from
Aug 9, 2018

Conversation

danxuliu
Copy link
Member

@danxuliu danxuliu commented Jul 16, 2018

Server part of nextcloud/spreed#1050

This pull request, with its Talk counterpart, makes possible to share a file or folder into a Talk room.

Due to the current architecture of the sharing system it is not enough to provide an IShareProvider to add a new type of share; the controllers for the sharing API also need to be modified to support each type of share. Due to this, and to keep the server isolated from the Talk details (for example, whether a file can be shared with certain type of room or not, or how to generate the display name for a room share), the controllers just delegate those checks or actions to helper classes defined in Talk.

Besides that, each type of share needs to be referenced throughout the server code in order to be taken into account for certain operations, like providing the share type in DAV properties or transferring the ownership of files and shares to a different user.

While implementing this I have found some issues in the existing sharing code (like some types of sharing not being audited, a strange behaviour moving received shares into other received shares, or some shares being wrongly deleted when transferring ownership due to their name); those issues will be fixed in other pull requests.

Also note that this pull request implements room shares, but not search for room collaborators (so even if room shares are implemented you can not test them from the UI); this is implemented in #10256

@@ -12,6 +12,7 @@ OC.Share = _.extend(OC.Share || {}, {
SHARE_TYPE_CIRCLE:7,
SHARE_TYPE_GUEST:8,
SHARE_TYPE_REMOTE_GROUP:9,
SHARE_TYPE_ROOM:10,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we use TALK instead of ROOM
it reflects a bit more what the value is about, also as we stop using the term room in the UI it's better for other devs

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought about using TALK, but in the end I opted for ROOM because I think it is more accurate, as it describes exactly the element that you are sharing with, and is consistent with the names of the rest of share types; I find TALK too abstract, and maybe in the future there will be other types of shares that can be done through Talk too. Opinions?

* @return RoomShareProvider
*/
protected function getRoomShareProvider() {
if ($this->roomShareProvider === null) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could do an event here, so there is less Talk code in the server repo?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we add an event here I think that it would make sense to move all the other providers to that generic system too, but if we do that then it would be something for a separate pull request.

@danxuliu danxuliu force-pushed the add-support-for-room-shares branch from d9d2cc2 to aa5c1d1 Compare July 16, 2018 16:45
@danxuliu danxuliu force-pushed the add-support-for-room-shares branch from aa5c1d1 to db94579 Compare July 23, 2018 20:13
@danxuliu
Copy link
Member Author

Phan complains that:

apps/files_sharing/lib/Controller/DeletedShareAPIController.php:145 PhanUndeclaredClassMethod Call to method formatShare from undeclared class \OCA\Spreed\Share\Helper\DeletedShareAPIController
apps/files_sharing/lib/Controller/ShareAPIController.php:244 PhanUndeclaredClassMethod Call to method formatShare from undeclared class \OCA\Spreed\Share\Helper\ShareAPIController
apps/files_sharing/lib/Controller/ShareAPIController.php:920 PhanUndeclaredClassMethod Call to method canAccessShare from undeclared class \OCA\Spreed\Share\Helper\ShareAPIController

Those classes are used only when they exist (otherwise an exception is thrown, which is then caught and the code goes on happily); should I add a Phan exception or just change the declared return type to object?

@MorrisJobke
Copy link
Member

should I add a Phan exception

This ;)

@MorrisJobke MorrisJobke mentioned this pull request Jul 24, 2018
21 tasks
@danxuliu
Copy link
Member Author

Oops, now that share notes were merged the unit tests need update; I will take care of that.

@danxuliu danxuliu force-pushed the add-support-for-room-shares branch from 83aab19 to cd65e3e Compare July 24, 2018 11:31
@MorrisJobke
Copy link
Member

Oops, now that share notes were merged the unit tests need update; I will take care of that.

Looks like another round of rebase is needed 🙈

@danxuliu danxuliu force-pushed the add-support-for-room-shares branch from cd65e3e to a693e11 Compare July 25, 2018 07:59
@danxuliu
Copy link
Member Author

Looks like another round of rebase is needed 🙈

Done; it was only a matter of adjusting the ShareAPIController constructor due to the AppManager being already passed in #10238.

@MorrisJobke
Copy link
Member

What is the status here? Either in the beta 1 or in 15.

@nickvergessen
Copy link
Member

I fear to rsh in a workflow direction we might not want in the end
we had a long discussion at lunch yesterday how files + talk could work together and how people think stuff should work
at some point we also need to allow people to upload stuff in chat
which would create a folder for each room, and then things get very complicated pretty fast
also this approach does nto work for guests
so not sure if we should do this step, because it's not revertable

@schiessle mind to comment your opinion?

@MorrisJobke
Copy link
Member

We should think also about the UX for where to store the files that are uploaded to rooms directly as well.

@nickvergessen mentioned to put them in one folder per room. Also where to do the guest uploads.

IMO this should be put into the app data directory. I think the deck app does this as well. Because those files are not related to the users file system, but to the app itself. cc @juliushaertl

@danxuliu
Copy link
Member Author

I say merge this for Nextcloud 14.

This pull request simply makes possible to provide room shares. But it does not force us to provide room shares. As long as the RoomShareProvider and the helpers for the controllers are not included in Talk there is no support for room shares.

If this pull request is merged and it is later decided that room shares is not a good approach to share files in Talk there is no problem. The pull request is reverted for 15 and done. There would have been no provider, so no room shares would have been ever created, no database cleanup needed, no removed feature, nothing; just some code gone.

However, if this pull request is not merged and it is later decided that room shares is the way to go then there would be no chance to add them before 15. Instead, if the pull request is merged then there would be no problem in adding the support for Talk 4.1, 4.2 or something like that.

The only reason that this pull request is needed is because the sharing API is not yet abstract enough for apps to provide new share types without touching the server.

Regarding uploading files to chats, my idea is based in room shares (obviously :-P ). All the files in chats would end inside the Talk folder (configurable name, like the share folder). When the user uploads a file in a chat the file would be uploaded to that folder (or maybe a Sent subfolder) and automatically shared with the room; the other participants in the room would be able to access that file from their own Talk folder (or maybe a Received subfolder).

In any case this would simply need to add a new mount provider in Talk based on OCA\Files_Sharing\MountProvider and OCA\Files_Sharing\SharedMount. Besides the benefit of reusing code it also has the benefit of behaving in a consistent way with other shares, although slightly adapted to this specific use case.

In the Talk UI then it would be possible somehow, maybe in the sidebar, to get a view of all the files uploaded/shared in a specific conversation (which using room shares would be trivial, just search all the files shared with the room and done, even if they were moved to another folder).

Also, in the same way that the Files app provides a special view for shares, it could also provide a special view that groups the files by folders with the name of the conversation. Or simply upload and receive them in a subfolder of Talk with the name of the conversation. I guess that as long as the folder id is not modified the clients would be clever enough to just rename them when syncing again if the conversation was renamed since the last sync.

Finally, regarding guest users, my idea was to create a public shared link for a file when it was shared with a public room. However I have not added it yet because currently it is not possible to create more than one share link for a file; I felt that it would be better to wait until that is supported so a read-only share link could be created for guests of the room without preventing the user to also create an editable link by herself.

To allow guest users to also upload files in the chat my idea was to somehow connect a public shared folder with a room, although I have to admit that I have not thought about it yet.

In any case, even if you see a lot of problems with all that, this pull request does not force us to implement anything of it. Again, it makes possible to do it in a later version of Talk, but if those ideas end being scrapped then there is no problem if this pull request was merged; just revert it and everything will be fine.

@schiessle
Copy link
Member

Where will guests upload files?

Maybe even more important question for the first iteration: How can a guest access files shared to the room? Will we create public links for guests? How does the guest receives the link?

@danxuliu
Copy link
Member Author

Maybe even more important question for the first iteration: How can a guest access files shared to the room?

For the first iteration my idea was that guests could not access files shared with the room. Having said that...

Will we create public links for guests?

I guess that we could simply create a token for shares with a public room so they can be downloaded through a public link (like mail shares or link shares). But this may need some changes in the server.

Alternatively we could automatically create a public link share when a file was shared with a public room. However it would have the problem mentioned above about not being able to create more than one link share for a file, and I think that the other approach would be much cleaner.

How does the guest receives the link?

When a file is shared with a room a new message will appear in the room (it is not implemented yet, but it only requires changes in Talk). The message will be parsed by the Web UI and it will show the appropriate URL to download the file depending on whether the participant is a registered user or a guest.

@schiessle
Copy link
Member

I guess that we could simply create a token for shares with a public room so they can be downloaded through a public link (like mail shares or link shares). But this may need some changes in the server.
Alternatively we could automatically create a public link share when a file was shared with a public room. However it would have the problem mentioned above about not being able to create more than one link share for a file

As it will not be a link share but a "room share" your own share provider you should be freed from the limitation that there is only one public link allowed per file. We do the same for mail shares. Technically it is exactly the same as a link share but because it is a different share type the limitation doesn't kick in.

Btw, this was the initial, super simple idea to just create such a link and post it to the chat so that everyone can access it. Your implementation is far more advanced, with a better user experience for internal users but with the drawback that it doesn't work for guests.

@danxuliu
Copy link
Member Author

danxuliu commented Aug 1, 2018

Your implementation is far more advanced, with a better user experience for internal users but with the drawback that it doesn't work for guests.

Not any longer ;-) I have added tokens to room shares, so now room shares for public rooms can also be accessed by guests.

@rullzer rullzer mentioned this pull request Aug 2, 2018
58 tasks
This type represents shares with a Nextcloud Talk conversation.

Signed-off-by: Daniel Calviño Sánchez <[email protected]>
Signed-off-by: Daniel Calviño Sánchez <[email protected]>
The RoomShareProvider is provided by the Talk app, so it is necessary to
check whether the app is available or not, and also whether the class
itself exists or not (just in case an older version of the app that did
not have support yet for room shares is being used).

Signed-off-by: Daniel Calviño Sánchez <[email protected]>
Room shares are implemented in an external app (Nextcloud Talk), so in
order to keep the share manager as isolated as possible from room share
specifics all the validity checks are done in the provider of room
shares. However, due to the code structure it is necessary to explicitly
check for room shares in "generalCreateChecks" to prevent an exception
from being thrown.

Signed-off-by: Daniel Calviño Sánchez <[email protected]>
In some cases, the ShareAPIController requires explicit handling of each
type of share (for example, to format a share for a DataResponse). Room
shares are implemented in an external app (Nextcloud Talk), so in order
to keep the controller as isolated as possible from room share specifics
all that explicit handling is done in a helper class provided by the
Talk app.

In other cases it is just enough to call the share manager specifying a
room share type; note that the share manager is guarded against share
types for which there is no provider, so it is not necessary to
explicitly check that before passing room shares to the share manager.

Signed-off-by: Daniel Calviño Sánchez <[email protected]>
In some cases, the DeletedShareAPIController requires explicit handling
of each type of share (for example, to format a share for a
DataResponse). Room shares are implemented in an external app (Nextcloud
Talk), so in order to keep the controller as isolated as possible from
room share specifics all that explicit handling is done in a helper
class provided by the Talk app.

In other cases it is just enough to call the share manager specifying a
room share type; note that the share manager is guarded against share
types for which there is no provider, so it is not necessary to
explicitly check that before passing room shares to the share manager.

Signed-off-by: Daniel Calviño Sánchez <[email protected]>
The test just ensures that the controller will gracefully reject the
creation instead of failing miserably; the integration tests when Talk
is enabled are in the Talk repository.

Signed-off-by: Daniel Calviño Sánchez <[email protected]>
The MountProvider for shares creates mount points for the files shared
with the user, which makes possible to use the received shared files and
folders as regular files and folders.

Signed-off-by: Daniel Calviño Sánchez <[email protected]>
A user can move her own shares into a received share. When that happens
she is effectively handing over the ownership of the file, so the share
needs to be updated to reflect the new owner.

Signed-off-by: Daniel Calviño Sánchez <[email protected]>
Like done for other types of shares, room shares are now explicitly
described as such in the UI.

The avatar used is the image provided in the "shareWithAvatar" property
of the share. If none is given then the avatar is the first letter of
the display name of the room share with a coloured background seeded
from the room token. If the display name of the room is empty then no
letter is shown in the avatar; no special handling is done in that case.

Signed-off-by: Daniel Calviño Sánchez <[email protected]>
Like done with group shares, received room shares are described as such
in the UI.

Signed-off-by: Daniel Calviño Sánchez <[email protected]>
The DeletedShareAPIController and ShareAPIController helpers for room
shares are defined in Talk, so the classes do not exist when Talk is not
installed. Due to this when the object returned by "getRoomShareHelper"
is used Phan complains that the class is not declared.

This is not a problem, though, because when the class is not available
"getRoomShareHelper" throws an exception, which is then caught where
that method was called. Therefore now those warnings from Phan are
suppressed (it would be better to use "@phan-suppress-next-line"
instead, but it is not yet available in our Phan version).

Signed-off-by: Daniel Calviño Sánchez <[email protected]>
Tokens will be used to give access to a share to guests in public rooms.
Although the token itself is created in the provider of room shares and
no changes are needed for that, due to the code structure it is
necessary to explicitly call the provider from the manager when getting
a room share by token.

Signed-off-by: Daniel Calviño Sánchez <[email protected]>
@danxuliu danxuliu force-pushed the add-support-for-room-shares branch from a0c1f49 to 4b7fa4a Compare August 8, 2018 12:51
Copy link
Member

@rullzer rullzer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok lets do this 🐘

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants