Else, if a client calls addContact with an invalid uri, it will
create a conversation with an invalid contact and the client will
be in a bugguy state.
git.jami.net/savoirfairelinux/jami-client-android/-/issues/1681
Change-Id: Id6227c45c279c78aac0a191b6ae688ebe0d3d1c4
This allow users to delete files. Moreover, change edited type and
use edited commit type instead.
GitLab: #796
git.jami.net/savoirfairelinux/jami-client-qt/-/issues/1287
Change-Id: Ida04c15cf1570de2f7707ce547be9f4a5e638245
API changed for ut_conference.
For ut_conversation_call, because the host is not a dummy call,
we must change the hangup in manager.cpp and fix sink creation
for host while attaching.
Change-Id: Icfc296949438e92f7b9b986ed6aa3b463ec2334e
Now a conference can start without any call (this avoid to attach
a call without peer to create a conference).
Path is now clearer for a call creation:
+ If we receive a call, we attach it to the conference
+ Else we do not create any call and just attach the host.
Next step is to be able to attach a host in audio only without weird
tricks and group addParticipant/bindParticipant
GitLab: #953
Change-Id: I13785a5525e041c37fb62c0c9f355e9371f1e4ad
Also, start to fix audio binding (this will be a full patch, but
at least do not attach host)
GitLab: #959
Change-Id: I0aeb9121e2880a5afb4b1ca1a30710d1b60a2e7e
+ Avoid concurrent operations on same repository
+ Reset HEAD to always get a clean commit
GitLab: #931
Change-Id: If417c06934e2acab3382481718dc0bc46f40e3f9
If a conversation is syncing, conv->infos() is not available and
there is no conversation request. So we must keep metadatas somewhere
to be able to show profile of a conversation while syncing
Change-Id: If68e8476f456ab13a5523193d67bb1212e1cb46a
If last message is displayed, the cache upgrade wasn't working because
we only checked from sending to sent, not sending to displayed and
status was lost after a reboot
Change-Id: I5d11e7560edf000e6fd9b8d3173d660baf0cc944
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
