Sébastien Blin authored 1 year ago and Adrien Béraud committed 1 year ago

This fix the error "No conversation detected for..."

Change-Id: I95769b89ceac6c03bc8abab87978e154500a6319

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

Alireza Toghyiani authored 1 year ago and Adrien Béraud committed 1 year ago

Change-Id: I8926afa1e36352264ce2450c248c2c498ba2a0cf

Kateryna Kostiuk authored 1 year ago and Adrien Béraud committed 1 year ago

Change-Id: Ib5e9798673fc7877f4fe12ac419acb3be1b1dde8

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

Change-Id: Ie525f767ab3985e54be6420bd3d3346b040d487b

Adrien Béraud authored 2 years ago and Adrien Béraud committed 1 year ago

Change-Id: I915fe38db6547425cdccc516d05ebd9afcdb3aac

Adrien Béraud authored 2 years ago and Adrien Béraud committed 1 year ago

Change-Id: I72f04851b56d37a9264b78c10c0819e48712c6f9

Adrien Béraud authored 2 years ago and Adrien Béraud committed 1 year ago

Change-Id: I1c4b30bee4cac1767b53353799ac819faf95a9cb

This reverts commit 65c86319.

Reason for revert: I see only this commit that can cause duplicates to appears. Will check without

Change-Id: I3a36a59fb87c8cddaa7c9020112efabe9073a041

The fallback can take up to 30 seconds, so wait a bit longer

Change-Id: I357ef48a43873396e575f70c2a1c391df8f5a655

For a declined channel, onReady wasn't called. Only onShutdown()
causing all waiting callbacks to be declined if the connecting
channel was declined.
Now onReady is always called if channel is declined or accepted,
so we call all callbacks correctly. This fix sporadic failures
in testMultipleChannelsOneDeclined where the git channel was
declined as the connecting channel.

Change-Id: I0ff7550c2f35cbcf20aaf796d56badfb18bec515

Currently, when a contact accepts an invitation while
iOS is in the background, the extension stops the
daemon before synchronization is completed. This
patch allows the client-ios to know when the fetch
is completed, so it can wait until the conversation
is cloned.

GitLab: #776
Change-Id: I123f3ca94c1cece1138db09d536f48e6533cf78f

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.

Change-Id: I4095ee59d56a28c4a24f8f4ddd9116109e6d0b7c

Else we can replace the first notification to send and create
some weird race-conditions. Fix testMemberBanNoBadFile

Change-Id: I5b902cf67fe5647faaef7801ad6ce380cd801c78

Change-Id: If56a102c1861b762623acdbe11358b0bc85085c5

Due to certStore changes, we should force the certificate pinning
after forceReloadAccount

Change-Id: I1a98f86847607e9c48b91b5448185e3d25763a49

If all pending connections fails, it should remove all waiting callbacks
and not only the connecting one.
So, introduce a structure to make the difference between PendingCb linked
to a ongoing DHT request and others waiting for the request to finish.
If all ongoing requests fails, all waiting callbacks are called. This
avoid wrong "Already connecting" messages.

Change-Id: I518f1ef85294f55f78d1b75638b1612c68ea0a0a

We're in 2023 and supporting c++17, every supported compiler should
have correct headers.

Change-Id: I81bda5df7a54a0943529d37d20e2852c651c8c6b

jami-client-qt#681
jami-client-qt#880
jami-client-qt#908

Change-Id: Idcf20c821cf0b619d9ee6ccfcaf3ba153622a679

Sébastien Blin authored 2 years ago and Adrien Béraud committed 1 year ago

Change-Id: I4fe092e978d77213ebf29fea9d2a256bd1954d6c

GitLab: jami-plugins#38
Change-Id: I42b4f25460285a677a226671bf85e0c1039e7c37

Change-Id: Id84e465996138a16aa425dde37baa389240f4221

Else, we can see several deadlock (closeVideoInput() will wait
forever, because a signal is emitted before the method is finished
causing a deadlock in sdbus-cpp)

Change-Id: I87d5a5d51e80f3b75e60354595f8c618def361ff

Change-Id: I50749a002936da4159be9479f256aa45fce64221

Vladimir Stoiakin authored 1 year ago and Sébastien Blin committed 1 year ago

Change-Id: If10740b4fd192a1043c5f83adc9072fe67df7862

Sébastien Blin authored 1 year ago and Adrien Béraud committed 1 year ago

Change-Id: I4627179aefe44e7cc0720c28076f70d2aaf17b0c

Sébastien Blin authored 1 year ago and Adrien Béraud committed 1 year ago

Else, passing the path and not the content of the file will cause:
Could not read certificate - ASN1: error in TAG

Change-Id: I2db356d1ccf8d3b059072cc14e64df8369f84e77

Kateryna Kostiuk authored 1 year ago and Sébastien Blin committed 1 year ago

If client calls some APIs from the account, convModule_ may be
un-initialized if the account is not yet ready, causing potential
segfaults

Change-Id: If47c9d5466e42dee58ea1ebbdd71404ee94a82d1

convModule()->bootstrap should not use configurationMutex_ while
locking conversations. Else we may have:
thread 1: configurationMutex_->conversationsMtx_
thread 2: conversationsMtx_->configurationMutex_
causing a deadlock

So, retrieve known devices before bootstrapping the conversation

Change-Id: Ib194edaa255b5ffde9e58ea7e0be0226943bb118

This will output to the "Output" pane in Visual Studio.

Change-Id: I74e229670c990f09af247b02dc3ae753ad7db9c6

Sébastien Blin authored 1 year ago and Andreas Traczyk committed 1 year ago

Change-Id: I9ef704107897a0a057e7d43feeb24d5e2eb73679

Else, it can cause a message forever sending.

https: //git.jami.net/savoirfairelinux/jami-client-ios/-/issues/281
Change-Id: Ia3bbf508a955137c5d57d8f7b45b2f6b0ac232be

Kateryna Kostiuk authored 1 year ago and Sébastien Blin committed 1 year ago

It is unnecessary because the device performs synchronization
during the bootstrap. Moreover, it could result in the
failure to receive notifications on iOS because iOS does not
respond to sync connections in the background. However, the
other side may consider it as already connected.

jami-client-ios#281

Change-Id: Id55e7bfaafba1e45a6c27afdebf682c33acd9d30

Change-Id: Ibb8963b9aa02c21e5382413b7918f0e1e0baea4a

Sébastien Blin authored 1 year ago and Adrien Béraud committed 1 year ago

We use GNUTls >= 3.6.7 so this is always true.

Change-Id: Ifcc996a95faf056a3c0eed35cffc17becddeeed3

Change-Id: I157118c875868aa1cae7d0b0ea02644175d33b70

The check in this loop is useless as we already have the transport
that we are searching for. Moreover, locking sipConnsMtx_ from
a pjsip operation (here sipvoiplink) may cause a deadlock.

Change-Id: Ic263d69a3f5518857a93a4a4576a4a63b7fda575