-
-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
Add support for room shares #10255
Conversation
0006684
to
d9d2cc2
Compare
@@ -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, |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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) { |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
d9d2cc2
to
aa5c1d1
Compare
aa5c1d1
to
db94579
Compare
Phan complains that:
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 |
This ;) |
Oops, now that share notes were merged the unit tests need update; I will take care of that. |
83aab19
to
cd65e3e
Compare
Looks like another round of rebase is needed 🙈 |
cd65e3e
to
a693e11
Compare
Done; it was only a matter of adjusting the |
What is the status here? Either in the beta 1 or in 15. |
@schiessle mind to comment your opinion? |
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 |
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 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. |
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? |
For the first iteration my idea was that guests could not access files shared with the room. Having said that...
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.
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. |
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. |
Not any longer ;-) I have added tokens to room shares, so now room shares for public rooms can also be accessed by guests. |
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]>
Signed-off-by: Daniel Calviño Sánchez <[email protected]>
Signed-off-by: Daniel Calviño Sánchez <[email protected]>
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]>
a0c1f49
to
4b7fa4a
Compare
There was a problem hiding this 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 🐘
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