You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Since #4316 is merged and got into 1.113.0 if 1:1 chat with the contact is blocked, groups that it create are also blocked and are not just contact requests.
However, I think this change should have checked if the contact is blocked rather than if 1:1 chat with the contact is blocked. 1:1 chat being blocked does not mean that the user blocked the contact, it also happens when the user scans a group QR code with unknown inviter and 1:1 chat with the inviter is blocked to hide it:
// A 1:1 chat is needed to send messages to Alice. When joining a group this chat is
// hidden, if a user starts sending messages in it it will be unhidden in
// receive_imf.
let hidden = match invite {
QrInvite::Contact{ .. } => Blocked::Not,
QrInvite::Group{ .. } => Blocked::Yes,
};
let chat_id = ChatId::create_for_contact_with_blocked(context, invite.contact_id(), hidden)
.await
.with_context(|| format!("can't create chat for contact {}", invite.contact_id()))?;
This has caused problems with running mailadm tests. There, bot admin joins an administration group via the QR code. This results in creation of two chats with the bot: blocked 1:1 chat and unblocked group chat. Group chat joined via the QR code is explicitly created as unblocked:
Then outside user writes a message to the bot and the bot relays this message to the new support group named "[email protected] support group" where it adds all admins (only one in the test). But the admin has 1:1 chat with the bot blocked and this triggers blocking of the support group as well.
This issue prevented us from upgrading mailadm to versions of the core >=1.113.0: deltachat/mailadm#126 (comment) But not upgrading only helps the tests to pass, while in reality if admins use core >=1.113.0 they may not see the support group at all.
Since #4316 is merged and got into 1.113.0 if 1:1 chat with the contact is blocked, groups that it create are also blocked and are not just contact requests.
However, I think this change should have checked if the contact is blocked rather than if 1:1 chat with the contact is blocked. 1:1 chat being blocked does not mean that the user blocked the contact, it also happens when the user scans a group QR code with unknown inviter and 1:1 chat with the inviter is blocked to hide it:
deltachat-core-rust/src/securejoin/bob.rs
Lines 33 to 42 in 4d74f62
This has caused problems with running mailadm tests. There, bot admin joins an administration group via the QR code. This results in creation of two chats with the bot: blocked 1:1 chat and unblocked group chat. Group chat joined via the QR code is explicitly created as unblocked:
deltachat-core-rust/src/securejoin/bob.rs
Line 190 in 4d74f62
Then outside user writes a message to the bot and the bot relays this message to the new support group named "[email protected] support group" where it adds all admins (only one in the test). But the admin has 1:1 chat with the bot blocked and this triggers blocking of the support group as well.
This issue prevented us from upgrading
mailadm
to versions of the core >=1.113.0: deltachat/mailadm#126 (comment) But not upgrading only helps the tests to pass, while in reality if admins use core >=1.113.0 they may not see the support group at all.cc @Hocuri
The text was updated successfully, but these errors were encountered: