There is no need as we always merge two branches so we can avoid
a lot of recursive operations. Moreover, this seems to cause some
weird locks
To be honest I'm not sure about the usage of this argument, doc is
still a bit unclear:
Maximum number of times to merge common ancestors to build a
virtual merge base when faced with criss-cross merges.
When this limit is reached, the next ancestor will simply be used
instead of attempting to merge it. The default is unlimited.
GitLab: #871
Change-Id: I9c22208626e7f6ff489e91b72a580238a6137499
Patches a fix made for GitLab: #732. This should still prevent the segfault as the only case it would occur is in the startReceiver()
GitLab: #873
Change-Id: I07b4c980c55697633f7aade00c0b7f242af10b45
This distinction between informations from the backend and user
preferences on the codec is not really useful and introduces some
useless complexity.
GitLab: #804
Change-Id: Ieff85e748c635941b1a5efed77b023be41c91b4b
If Alice removes Bob and Bob sends a new message, a new request
is received (because Alice doesn't block Bob). However, the
next acceptConversationRequest was not adding correctly Bob into the
contact list, because no trust request were generated (so getContacts()
in this case was returning an invalid list).
This patch ensure that the 1:1 conversation requests are similar to
the trust requests list.
Change-Id: I643d70a016ef549d69ff03a227488b10bfb8d73f
The conversation requests doesn't need to be locked when getting trust requests and may provoke a deadlock.
Gitlab: #864
Change-Id: I64e11a9ef1343f51785479f2b577fffa8ebfbf7c
ServerAccountManager didn't implement any onSyncDatas, causing
contacts to not sync across devices.
Also small fix: do not try to clone conversation already, it was
adding a useless log.
Change-Id: I494ee75ee0313c05056ee83ddcb8d9be500f593a
An account can try to connect to a device that the presence was never
yet detected on the DHT but can use the public key from the repository.
Bootstrap can use devices from the repository.
Moreover, do not try to bootstrap with expired devices, as they are
invalid anyway, so the connection will obviously fail.
Change-Id: I5493419681e88fa3f920efabb0ab7019319c05fd
This allow to avoid to get a duplicate if a contact is added,
removed and re-added (as it will generate two conversations).
The first one is automatically declined and replaced by the new one.
GitLab: #855
Change-Id: I67d51d2286aaee3b29c9e9bdbcb10aa45f40aa26
If a contact is added, removed and a new trust request generated
and removed with "removeContact" it wasn't removing the trust request
because the contact wasn't considered as active and the banned status
didn't change.
Removing this return condition force all components to update and
supports client if they use removeContact instead of declineTrustRequest.
This avoid useless complexity with isActive, because if isActive() is
false, removeContact will not change the result and isActive() will
still return false.
A test is added.
GitLab: #855
Change-Id: I4385c2a480f6cfa5de3785a08bc2193eeb9a24a1
+ dbusinstance: count_ can be initialized to something else than 0
causing count_ to always be incorrect
+ ring_api: check pointer for ioContext() (because a callback may
be emitted right after ioContext() is resetted causing to end
on a segfault instead exit=0)
GitLab: #861
Change-Id: If0d798aaa2ce7d65426d902868627bd701652375
Since the DRT, we're not using trackPresence to start syncing
with other members of the conversation but "bootstrap".
For bootstraping conversation's requests we should try to clone
it with the members marked in the convInfo.
Also fix one incorrect test.
Change-Id: I8cbefe266c15c637ef23350220a71a616ddefab6
This reverts commit 65c8631975.
Reason for revert: I see only this commit that can cause duplicates to appears. Will check without
Change-Id: I3a36a59fb87c8cddaa7c9020112efabe9073a041
