Now mentioned users are notified only if they are already participants
of a private chat (a one to one chat, a group chat, or a password
protected public chat), or if the message was written in a public chat.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The chat message can be much longer than the maximum length allowed for
notification messages, so the notification message is trimmed if needed.
When the notification is being prepared to be displayed it is taken into
account if the message was trimmed, and in that case an ellipsis is
added at the start and/or the end (depending on the case) of the
message.
Note that the original notification message does not contain the
ellipsis characters, as depending on the language a whitespace should be
added or not before and after an ellipsis, and the language in which the
notification will be displayed is only known at the time of displaying
it, but not when it is saved.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When a user is mentioned in a chat message she will now receive a
notification about that. If a chat room is deleted all the pending
notifications will be also removed.
The rich subject of the notifications use "call" instead of "room" or
"chat" due to "call" being already available in
"lib/public/RichObjectStrings/Definitions.php" (in Nextcloud server),
although the Notifications app does not handle it in any special way
though ("apps/notifications/js/richObjectStringParser.js").
Note that, unlike with the current code for invitation notifications, no
checks are made on whether "call" is available or not, as the chat is
available only from Nextcloud 13 and onwards.
Currently every user mentioned in a chat message is notified, but this
will be tightened in later commits (for example, if a user is mentioned
in a chat room to which she is not able to join).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Since commit eae71a3977 a participant
(user or guest) can be in a room without joining a call; since then
sessions are no longer set and passwords are no longer checked when
joining a call, but when joining a room. Due to this some integration
tests had to be modified to join a room instead of a call.
Note, however, that in the modified tests there is no need to join a
call too once the participant has joined the room, as they either test
joining the room itself (the password tests) or the tested actions
simply need the participant to be in a room (the chat tests). Moreover,
in this later case, note that a participant is in a room if she created
a room, was invited to it or explicitly joined it, so the chat tests
involving a participant creating a room or inviting another one to it
did not need to be modified.
Finally, neither the call tests nor the "userJoinsCall" method from
FeatureContext were modified yet, as it has to be decided first whether
directly joining a call also joins the room automatically or not.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Before, any user was able to send and receive messages to and from
public password protected rooms, even if they were not invited and they
had not joined it; guests were not able to send, but were able to
receive nevertheless. Now, only invited users or users/guests that have
joined a public password protected room can send and receive messages to
and from it.
As a side effect that change affects too to regular public rooms (not
password protected), but the new behaviour makes more sense than the old
one anyway.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The character limit for actorId is 64, but the spreed-session is 256
characters long, so it has to be hashed to get an ID that fits.
The sha1 algorithm is used as, from all the hash functions bundled with
PHP that are always available (the Hash extension can be disabled using
the "--disable-hash" switch, unlike those that are part of the string
functions), it generates the longest hashes (40 characters) that fit in
the actorId column of the database.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The ChatController uses a long-polling approach: if there are currently
no messages the response will not be sent immediately; instead, HTTP
connection will be kept open waiting for new messages to arrive and,
when they do, then the response will be sent.
The technique is simply based on the fact that ChatManager will wait
(hang) until there are some messages to be returned, or until the
timeout expires.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The chat manager handles sending and receiving chat messages. It uses
basic polling; "receiveMessages()" will repeteadly query the database
for new messages, waiting a little between each query, until messages
are found or the timeout expires.
The Comments API is used internally, but as this class is meant to be
used directly and only by a Controller, "receiveMessages()" returns an
array of IComments too instead of a custom interface to save the
conversion of objects.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Besides returning the last element, "end" also sets the internal pointer
of the array to the last element, and for that it receives a reference
to the array. Thus, "end(array_keys(..." can not be used, as it would
generate the Strict Standards error "Only variables should be passed by
reference", so the returned value from "array_keys" has to be stored in
a variable.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When running the integration tests through "run.sh" the parent directory
of the Spreed application must be the "apps" directory of an installed
Nextcloud server. Running the tests modifies the configuration and
database of that server, and the tests could fail too if the state of
its database conflicts with that expected by the tests.
The new "run-docker.sh" is a wrapper around "run.sh" that copies the
code (but not the configuration or data) of the Nextcloud server and its
applications to a Docker container, installs the Nextcloud server inside
the container (with a SQLite database), and then executes the
integration tests on the fresh server. This prevents the integration
tests from messing with the original Nextcloud server, and also ensures
that the integration tests will be run with a known initial state.
Besides that, when calling "run-docker.sh" the Docker image to be used
can be specified, so the tests can be easily run on PHP 5.6 or PHP 7.1
using "run-docker.sh --image nextcloudci/phpX.Y:phpX.Y-Z". If the
"--image" option is not given by default the image
"nextcloudci/php7.1:php7.1-15" will be used.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
As stated in the documentation for "uasort", "if two members compare as
equal, their relative order in the sorted array is undefined". "uasort"
is used in "RoomController" to sort the participants of a room by their
last ping, so when two participants have the same last ping they could
be returned in any order.
Although undefined, the order is probably consistent (so, whatever the
order is, it is the same between different executions for the same
data). When using PHP 7 the participants are sorted in the same order
that currently appears in the integration test definitions. However, PHP
5.6 uses a different order, so the tests fail in that case.
This commit adds sorting of the participants in a room returned by the
server, so they can be checked against the expected participant list no
matter the order used by the server; the list is sorted by default, but
that behaviour can be prevented adding ` [exact order]` to the
participant list in a test definition, so the participant list can be
checked in the exact order returned by the server too (for example, if
needed to check the participant list after setting the last ping for
them).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>