Now, a client should not do any logic and not store preferences
client side.
+ When a member is removed while banned, the typing indication
is updated
+ Timeout is computed both for sender and receiver
+ Sending and receiving a composing status is managed by the
account's config.
GitLab: #951
Change-Id: Iba9441736eec4f71695bfbd609d4b9e8b6adcb73
This should fix sporadic failured in ut_conversationMembersEvent
+ A banned member get a valid conversation still on the device.
+ Re-adding a contact updates the "removed" state
+ Avoid useless network operation if we're removing and fetching
at the same time
GitLab: #956
Change-Id: Ife3678d2ba35cb5ca61c8f22c64aa3400eae23d3
We recently changed getContactDetails() to get the removed state when
needed. However, getOneToOneConversation was now returning a removed
conversation causing the request to be ignored if both sides removed
them previously.
GitLab: #1619
Change-Id: Ie7464460609d6c1b6b3774318fb50116b7408f0a
This allow unit test to be able to check why a call is declined and
allow client to clarify messages for call messages
Change-Id: I37f8f1d1160910ca702010e4a9a40c9ecbcd13fd
Green indicator is not understandable for the majority of users.
This patch introduces a new approach to this status. API doesn't
change, so this is 100% backward compatible but introduces new
possibilities:
1. The status sent to the client is now 0=offline (no device found
on the DHT), 1=dht_presence (at least a device is found on the DHT),
2=connected (with a TCP + SIP channel, so ready to exchange data).
2. Publish can now be used on a Jami Account. Status is ignored,
but custom note can be added. e.g. "Lunch time!"
This status is sent via a PIDF XML status as described in RFC3863
(and already supported by SIP account) to connected peers (or for
future connections).
Several scenarios are tested in ut_presence
Change-Id: I87d987bc69e97f92a0c9f4751069e52ad69ea0fc
The test fails as this is not the current behaviour of MediaPlayer.
If this is considered as a behaviour we want, it should be done
and the test should be added at this point.
Change-Id: Ib3c76c72919e828b2be400095c24c474c2b1ce76
The goal of this patch is to allow the clients to get a better
sent/read status from the daemon.
API doesn't change much, but internal logic got some changes. For the
client:
+ SwarmMessage now contains a map<string,int> status where string is the
uri of a member, int is the status (0 = sending, 1 = sent, 2 = read)
+ cancelMessage is removed as not used anymore (sendMessage with flag=1
will edit a message)
+ getMessageStatus is removed as the status is sent in the SwarmMessage
+ accountMessageStatusChanged is now emitted for swarm messages when a
fetch or setDisplay occurs. Client must handle this signal correctly.
+ Previous code to manage last displayed, fetched status is now merged
with message status
+ Sync info is done when the sync is opened, else status are not updated
correctly
GitLab: #948
Change-Id: I60763d4de8a995c6fc9f6df6434e266211f8dc2f
+ addConversationMember was called without any conv ready sometimes
+ call was mostly disabled
+ ban/unban was unclear sometimes
Change-Id: I4919ec70af128a5bf623405ba6840a8fafc45e8c
If the first interaction from a device in a conversation is a
profile update, the certificate was not added correctly causing
the conversation to be illformed
GitLab: #946
Change-Id: I07f1735639c2dbf89ba2b2e6b7d9c3f57e5823e4
Because the encoded avatar can be greater than 64k, a SIP message
will fail, and the trust request may not be sent.
https: //git.jami.net/savoirfairelinux/jami-client-qt/-/issues/1491
https: //git.jami.net/savoirfairelinux/jami-client-android/-/issues/1537
Change-Id: Ieba2db521a3c7e72890be75d3578f93e496dc968
This heavily changes the API for the client. The goal here is
to move the logic to construct the history to show in the daemon
and not the client. This has several advantages:
1. Logic is common across every platforms, so bugs should not be
platform-specific
2. Client got less logic
3. Signal are simplified, if an edition comes, "MessageUpdated"
will be triggered instead MessageReceived.
4. Some tests are added for linearizing the history.
5. Search on edition is fixed.
Tests got heavily re-written, but the content didn't change (2 tests
are added, the rest is simplification).
GitLab: #831
Change-Id: Ie7c81077067e9e49db1dd396829c9225c0512c16
setKnownNodes will add new nodes that may be already connected
with a TCP link, but maintainBuckets may not choose those nodes,
delaying the bootstrap.
If we detect a new node that we're already connected with, we can
add it in the list of nodes we want to connect with.
Change-Id: I422a32495693e1e2d925a3af127a4a59903c1833
If we receive a conversation request for a contact where we
already have a conversation, we can just accept the new one.
GitLab: #924
Change-Id: I9e5d0f7302567ce488c52b45377117f034cd5da5
If first connection fails and presence is not tracked, the
conversation will not sync until the receiver restarts its jami,
causing the conversation to be stuck a very long time even if
peer is online and can sync.
In this patch, if we receives a trust request, we retry to sync
(this will be the case because the sender will re-send a trust
request to the contact who is still detected as an invited member)
GitLab: #922
Change-Id: I8866ceda98d50b0ddd2ea5402ef34f067f560e97
1. When a audio-only participant leaves, the video mixer is updated
and all audio-only streams are now removed.
2. If a audio-only calls try to join a swarm-call, it was hanging
due to a bad number of medias. So ignore video for audio-only calls.
GitLab: #917
Change-Id: Ifdd66e2ab138c078ef9e9c1402a07a6ae6a36b00
