This is called from time to time as well. Especially on big instances
having this proper indexed saves a lot of row scanning.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
In Chromium < 72 an extension is needed to share the screen
(https://github.com/nextcloud/spreed-screensharing-chrome-extension).
Once installed, the extension enables itself only in those pages that
contain an element with id "app" and class
"nc-enable-screensharing-extension" when the document is loaded.
As the element can not be added after the document has loaded and the
screen sharing should work also when Talk is enabled in other apps a
(hacky and very likely not compliant) meta element is added in the
header element to be found by the extension whenever Talk is used.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Note that the "path" property was already being passed to FilePreview,
although it was not explicitly declared.
At this time the Viewer can open only internal files, which are
available only for registered users. Therefore the Viewer is not loaded
for guests.
Also, for the time being, due to a limitation in the Viewer API, when a
file is opened the Viewer allows the user to iterate through all the
files in the directory of that file instead of through all the files in
the conversation, as it would have been expected.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The internal signaling server now filters signaling messages with type
"control" that are not sent by logged in moderators (including the
owner). This will be used, for example, to filter force mute messages
directly in the server, without needing to rely on the clients filtering
them.
The external signaling server already supports control messages,
although with a slightly different format (instead of being a subtype of
"message" messages they are their own "control" message). Therefore,
internally the WebUI uses the same format as the internal signaling
server for control messages and formats them as needed when sending them
to or receiving them from the external signaling server.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
In order to filter control messages the external signaling server needs
to know the permissions of each participant. Those permissions need to
be set when the participant joins the room or if the participant type is
changed.
All participants should have permissions to publish media and screen,
but only logged in moderators should have permission to send control
messages.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The external signaling server expects to receive a "participants"
message from the backend notifier when the participants in a room
change. This message is in turn sent as a participants update signaling
message to the clients, and the WebUI updates the list of participants
whenever that message is received.
However, when the type of a participant changes the backend notifier
sent an "update" message instead, which is in turn sent as a room list
update signaling message to the clients, but it does not trigger any
update in the participants list of the WebUI.
Now a "participants" message is sent too by the backend notifier when
the participants in a room change, so the WebUI updates the list of
participants when handling the participants update signaling message;
the WebUI could have been modified to rely on the room list update
signaling message instead, but using the other message seemed more
appropriate.
Note that the already existing "update" message sent by the backend
notifier is kept for now, as removing it may break the clients in
unexpected ways (although it should go away in the future).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Joas Schilling
Joas Schilling
Daniel Calviño Sánchez
Roeland Jago Douma
Joachim Bauch