Skip to content

Conversation

@danxuliu
Copy link
Member

@danxuliu danxuliu commented Aug 23, 2019

This pull request adds the Talk sidebar to the public share page, so users and guest can now chat and have calls when opening a link share.

  • Any user or guest can access the room for a file shared by link through the public share page (so they need the password of the link, if any).
  • The room is the same room used for any other share of that file. Therefore if a user has direct access to a file (that is, users that own or received the file through a user share, group share... so it is shown in the Files app) and the file is also shared by link the user can chat from the chat tab in the Files app (or the main Talk UI, or the public share page too) with guests currently in the public share page.
  • Users with direct access to the file can mention any other user with direct access to the file as well as any other user or guest currently in the public share page; users or guests in the public share page can mention users that have joined the room and other users or guests currently in the public share page.
  • The Talk sidebar is available only in the public share page of files, but not for folders. Unlike what happens with direct shares it is not available either for files inside a folder shared by link. This makes easier to implement the UI for the first version, but it could be changed in the future if needed.

This pull request is not finished yet. Here are the missing things:

  • The UI is not finished yet; besides the code being a copy/paste mess full of commented lines, there are issues like breaking the public share page layout or starting to load the chat messages before the sidebar has been fully shown, which breaks the visibility calculation of the chat messages and makes the chat view work strangely.

  • More importantly, the chat view does not work properly in the public share page for registered users when the internal signaling server is used (this can be seen in the failing acceptance tests), and it does not work at all when the external signaling server is used. The problem is similar to Wrong signaling ticket on video verification for logged in users #1537, but with a little quirk; even if the templates are modified to include the current user in the public layout it will still not work, because the ShareController enables the incognito mode in the public share page, so no user is returned by OC_User and thus the template will contain no user anyway.

    This could be fixed by applying Fix OC.getCurrentUser() on guest pages server#14178 to public pages too and removing the incognito mode for public share pages. However... I guess that the incognito mode is there for a reason :-P

    A different option (Edit: the one finally used) would be to fix it fully in Talk, without touching the server, by adding and endpoint to get the current user (or returning it along with the room token when calling the endpoint for PublicShareController::getRoom()) and then change all uses of OC.getCurrentUser() for a wrapper that checks if a user was explicitly got and if not fallbacks to OC.getCurrentUser(). @nickvergessen @rullzer Opinions on that? Any other idea is also welcome, of course ;-)

  • Another minor issues is that when a user with access to the file but who has not joined its room yet opens the public share page she is added as a participant of the room (and the "XXX joined the conversation" message is shown). If the user is joining through the public share page instead of through the Files app maybe she should be seen as a self-joined user and thus not join permanently the room?

  • Only tested with link shares; not tested with mail shares yet or any other share that uses a token.

Other things to consider for follow-up pull requests:

  • Currently the sidebar is shown for every file shared by link. (Fortunately) Guests can not mention users with access to the file but that have not joined the room yet, so those users are safe from spam notifications. Despite that, should it be possible to disable the public access to a specific file room? Where should be the option shown? Inside the chat tab in the Files app? And who should be able to disable the public access? Any user with access to the room?
    • According to @jancborchardt the sidebar should be shown for every file shared by link and there is no need to provide an option to disable the public access to a specific file room (that is, do not change anything from the current implementation).
  • The sidebar is always visible in the public share page. Maybe it should be hidden by default and be explicitly shown with an icon in the header, similar to how the sidebar works in Collabora Online?
    • According to @jancborchardt the sidebar should be shown by default; however, it should be possible to hide and show it again.

@danxuliu danxuliu added 2. developing enhancement feature: talk-sidebar ⬅️ Sidebar integration of Talk into other apps like sharing and documents labels Aug 23, 2019
@danxuliu danxuliu added this to the 💚 Next Major milestone Aug 23, 2019
@nickvergessen
Copy link
Member

18?

@danxuliu
Copy link
Member Author

Once I finish the UI the other pending issues should be easy and quick to fix once we agreed on how to proceed, so I would try to get this for 17 too to make @jospoortvliet happy :-P We can always defer it for 18 if turns out to be more difficult than expected.

@danxuliu danxuliu force-pushed the add-support-for-talk-sidebar-in-public-share-pages branch from 8e68917 to 21fac18 Compare September 26, 2019 03:47
@danxuliu
Copy link
Member Author

Once #2220 is merged this can be rebased and reviewed.

There are still two pending issues, but they should be handled in follow up pull requests (and, most likely, for a later release): do not permanently join the room when the user accesses it through the public share page (although it should be discussed whether that is needed or not) and provide buttons to open and close the sidebar.

@nickvergessen
Copy link
Member

To the rebase maschine 🤖

danxuliu and others added 17 commits September 26, 2019 10:45
Until now file rooms were available only to users with direct access to
the file. Now file rooms are available to any user or guest too if the
link is publicly shared (with a link share, for example).

Public shares are identified by a share token instead of a file id, so a
new endpoint, which is a counterpart of FilesController but for share
tokens, was added. The file room, however, is still associated to the
file id like before.

When checking if a participant can join a room if the current user is a
user without direct access to the file or a guest it is not even
possible to know if the file id belongs to a publicly shared file. Due
to this when the room is got for a share token the share token is stored
in the session and then used in following requests when checking whether
the participant can join a room or not.

Signed-off-by: Daniel Calviño Sánchez <[email protected]>
Signed-off-by: Daniel Calviño Sánchez <[email protected]>
Self-joined users and guests can join the room for a file if the file is
shared by link. In order to check that, however, the share token should
have been previously stored in the session, as the room is linked to the
file id and users without direct access to a file can not find out if
the file is shared by link or not. Therefore self-joined users and
guests must get the room for the share (which stores the share token in
the session) before being able to join the room.

Besides that, in the case of self-joined users they must be logged in
too. Otherwise the session is regenerated on each new request, which
prevents getting the share token stored in a previous request.

Signed-off-by: Daniel Calviño Sánchez <[email protected]>
File rooms were available only to users with direct access to the file,
so those were the users that could be mentioned. Now file rooms are
publicly available if the file is shared by link, so the mentions now
include all the users with direct access to the file like before plus
all the self-joined users and guests currently in the room.

Note, however, that self-joined users and guests can still not mention
users with direct access to the file that have not joined the room yet,
but only those that joined the room already (plus any participant that
is currently in the room).

Signed-off-by: Daniel Calviño Sánchez <[email protected]>
The absolute position causes the avatar container to have a different
height when the contained div has a text (guest avatars) or not (user
avatars, which use an image); now the flex property is propagated, which
causes the container to always have the same size as the contained div.

Signed-off-by: Daniel Calviño Sánchez <[email protected]>
When the public share page is loaded "publicshare.js" is initialized,
which modifies the page to add a Talk sidebar. The default layout has
the header, content and footer in a flex column; when the sidebar is
added the layout id modified to still have the header and content in a
flex column, but the content is now a flex row that includes
"#app-content" and the sidebar, and the footer is moved inside
"#app-content" so it does not affect the sidebar.

The Talk sidebar includes a call container at the top, which is only
shown during calls, and below it a call button and a chat view which are
always shown.

The CSS styles are a mix of the styles for the public share auth page
and the Files app, as well as some rules copied from the main
"style.scss" file.

Signed-off-by: Daniel Calviño Sánchez <[email protected]>
The "I see that the current page is the shared link I wrote down" step
is defined in the server but needs to be extended in Talk to also set
(in the tests) the Talk sidebar as the ancestor of the chat view.

In order to extend a step the whole Context that it belongs to must be
extended. Note, however, that the step in the child Context should not
include any "Given", "When" or "Then" annotation, as it would clash with
the step defined in the parent Context (the "Override" annotation is
simply informative, as it is ignored by Behat); as long as the method
has the same signature the step from the child Context will be used
instead if the step from the parent Context.

Signed-off-by: Daniel Calviño Sánchez <[email protected]>
…rectly.

This prevents joining the room for a file shared by link and protected
by password if the password has not been entered yet.

Signed-off-by: Joas Schilling <[email protected]>
When a user with access to a file joins its file room the user is added
as a persistent participant, so a "XXX joined the conversation" system
message is shown. However, if a user does not have direct access to a
file and joins its room the user is not added as a persistent
participant, so the system message should not be shown in that case.

Signed-off-by: Daniel Calviño Sánchez <[email protected]>
"OC.getCurrentUser()" gets its returned value from the "data-user" and
"data-user-displayname" attributes of the "head" element of the page,
which in some cases may not be the correct ones for Talk (for example,
in the public share page, as it uses the incognito mode which hides the
current user).

Signed-off-by: Daniel Calviño Sánchez <[email protected]>
The public share page uses the incognito mode, so "OC.getCurrentUser()"
never returns a user, even if the user is actually logged in. However,
Talk API requests honour the actual current user, so the Talk UI needs
to honour it as well.

Moreover, when the external signaling server is used, the Talk UI needs
to honour the current user not only to show the right user name and
avatar, but to be able to even connect with the external signaling
server.

Signed-off-by: Daniel Calviño Sánchez <[email protected]>
The default avatar size in VideoView is 128px, but due to the limited
space available in the public share page it is reduced to 64px in the
CSS. However, as "imageplaceholder()" is called while the element is
still hidden it does not get the size set in CSS, but the one given to
the function. This causes a mismatch in the text size once the element
is shown with a expected size of 128px on an avatar of only 64px, so the
same size should be used in both cases.

Signed-off-by: Daniel Calviño Sánchez <[email protected]>
@danxuliu danxuliu force-pushed the add-support-for-talk-sidebar-in-public-share-pages branch from 21fac18 to 891a73f Compare September 26, 2019 09:07
@danxuliu danxuliu marked this pull request as ready for review September 26, 2019 09:17
@nickvergessen
Copy link
Member

Looks good in general and the comments here are low priority.

The only thing I think we should change is:
Only join the room when the user clicked something, otherwise this feels like tracking/stalking.

@nickvergessen nickvergessen merged commit 918d6f9 into master Sep 27, 2019
@delete-merged-branch delete-merged-branch bot deleted the add-support-for-talk-sidebar-in-public-share-pages branch September 27, 2019 07:54
@nickvergessen
Copy link
Member

/backport to stable17

@backportbot-nextcloud
Copy link

The backport to stable17 failed. Please do this backport manually.

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

Labels

3. to review enhancement feature: talk-sidebar ⬅️ Sidebar integration of Talk into other apps like sharing and documents

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants