* Store the answer we generate so if we fail to send it, we can
try to send it again (doing the same again doesn't work as
webrtc is in the wrong state).
* Don't send ICE candidates if the call is ringing: queue them up
so we can send them later if we manage to actually send the
answer.
We won't have sent the invite anyway. Also termainate before we
fire the error event so the call is 'ended' when the event handlers
fire (which means if they try to hang up it's also ignored)
* If we can't send an invite due to unknown devices, abort the
call.
* Don't transition to the `invite_sent` state until the invite
has actually sent.
* Add a specific error code for failure due to unknown devices.
* Don't send ICE candidate messages if the call has ended.
* Add an `event` property to errors from `sendEvent` so that the
caller can resend or cancel the event.
Reverts https://github.com/matrix-org/matrix-js-sdk/pull/378
This swallowed all errors from sendEvent, breaking the ICE candidate
retrying. react-sdk no longer listens for send_event_error so I
think it's best to just remove this.
This is now a generic API on the homeserver. This is wrapped in a non-generic js-sdk function for now. In future, other group server implementations may want specific configuration and the configuration keys are namespaced to prevent collisions there.
Previously the global flag was used as a way to completely ignore the per-room option. This commit makes the per-room and global settings be more flexible to allow users to, for example, blacklist unverified devices in all room with the exception of one or two. This is done by making the global setting a device-level default and the per-room option allowing for 3 states: true, false, and unset (use device default).
Signed-off-by: Travis Ralston <travpc@gmail.com>
The API on synapse was modified to be an upsert, which means the same API call for adding a room to a group can be used to update the visibility of that association.
1. It's wrong because it doesn't consider the ban state
2. This should be caught by whether they have permission to send
the event in the first place rather than worrying about whether
it has notification permission or not
We were previously computing notifEvents at the point where we
processed them but before the room they belong to was stored.
This was problematic because some push conditions try to get the
room and therefore failed. Since the push actions are cached, this
spurious calculation also got cached.
This moves the calculation out to a separate function that gets
called only after the room has been stored.
Rather than trying to be clever and keep ones whose power level isn't
affected, since they'll still have an associated power_levels event
that isn't the one actually in effect, which could be confusing.
* Make setPowerLevelEvent() use getDirectionalContent() rather than
getContent(), otherwise power level events from pagination set
power levels the wrong way
* Don't assume the presence of a `users` key since the first
power_levels event in a room will have no prev_content
When a ppower_levels event arrived, the current member objects were
being updated but the sentinel members were not, meaning that the
power levels of RoomMember objects associated with events had stale
power levels. This was causing power level based push rules to
be wrong.
Specifically, add support for the sender_notification_permission
push rule condition. Also delays calculating notification events
until after they're added to the timeline, as per comment.
