Besides propagating the permissions to federated servers when modified
the existing permissions need to be set when creating the federated
conversation (or if a federated user is added again to the conversation
when all the previous federated users left it already).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When a participant does not have custom permissions the permissions are
got from the conversation, so they need to be propagated as well
to the federated servers to correctly calculate the participant
permissions.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The frontend gets the permission for the current participant from the
room data (as guest users can not get it from the participant list).
However, permission changes were not propagated to federated server, so
the frontend of federated users always assumed that the user had the
default permissions.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The permission only existed on API level and it's too complicated
to figure out a good UX for it. So the functionality to change it
are removed here. It's still kept in the database and response to
avoid breakage of existing clients
Signed-off-by: Joas Schilling <coding@schilljs.com>
When adding or removing call permissions the default room permissions
should be taken as a base if no call permission is set. Otherwise adding
will cause the permissions to be set instead of added, while removing
them will have no effect.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When adding or removing attendee permissions the permissions are
decomposed in each separate permission and added or removed
individually. However, the same query object was reused, so once it was
executed for the first permission found then it no longer worked as
expected for the following permissions.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When adding permissions to all attendees the permissions are added to
the call/room and to the attendees. Attendees with default permissions
will get the effective permissions from the call/room permissions, so
the permissions should be added only to those attendees that already
have custom permissions.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The call peer data is used by the iOS app to get information about the
peers in the call before the connection with the signaling server is
established, so the data can not be got from signaling messages and the
peer data endpoint should be available also in federated conversations.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
This is consistent with the behaviour for the rest of participants, as
the ping is updated when a participant joins the room, and it will be
needed for proper behaviour of integration tests that require an updated
ping.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Joas Schilling
Daniel Calviño Sánchez
skalidindi53
Sanskar Soni
provokateurin