-
-
Notifications
You must be signed in to change notification settings - Fork 81
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add self to the group when a MUA reply is received #4624
Comments
@anaskaejdar Thank you for your very detailed report. I think the origin of the problem is the fact that messages about the removal of group members are sent to the affected members as well. Thus, messages sent from a MUA as reply to all afterwards are not helpful and will re-add already removed members to groups. As we cannot prohibit a MUA group user to send messages to already removed group members, the question at hand would be how to deal with such situations. I could think of sending the removal message (which is the last a removed member is expected to receive) as bcc to the member who is about to be removed from the group. Then, when a MUA group user was about to reply to all afterwards, the removed member would not be applied to the list of recipients automatically anymore. |
This was likely introduced in #4185 The user being added back to the group as a result of a reply to an earlier message is expected, so as I understand the bug is that the removed user does not recognize that it is re-added. Then the solution is
|
Sounds good to me. The BCC idea is great, also. Additionally, maybe if DC thinks you've been removed from a group, rather than merely hiding the input fields, it could replace them with a little message explaining why they're gone, and a button to _un_hide them if the user wants. |
Other MUAs don't set add/remove headers, so the only way for them to re-add us to the group is to add us to To/CC/wherever. Previously it worked only for other members that are still in the group so that they properly handled our re-addition, but we didn't.
Other MUAs don't set add/remove headers, so the only way for them to re-add us to the group is to add us to To/CC/wherever. Previously it worked only for other members that are still in the group so that they properly handled our re-addition, but we didn't.
Other MUAs don't set add/remove headers, so the only way for them to re-add us to the group is to add us to To/CC/wherever. Previously it worked only for other members that are still in the group so that they properly handled our re-addition, but we didn't.
Fixed by #4638 |
…3782)(#4624) - If we don't know the parent (=In-Reply-To) message, then completely recreate the group member list (i.e. use the member list of the incoming message) (because we assume that we missed some messages & have a wrong group state). - If the message has a "Chat-Group-Member-Removed: member@example.com" header, then remove this member. - If the message has a "Chat-Group-Member-Added: member@example.com" header, then add this member. That means: - Remove all checks for the presense of `ContactId::SELF` in the group. Thus all recipients of a message take the same decision about group membership changes, no matter if they are in the group currently. This fixes a situation when a recipient thinks it's not a member because it missed a message about its addition before. - Recreate the group member list if we don't know the parent (=In-Reply-To) message, even if the sender isn't in the group as per our view, because we missed some messages and our view may be stale.
…3782)(#4624) - If we don't know the parent (=In-Reply-To) message, then completely recreate the group member list (i.e. use the member list of the incoming message) (because we assume that we missed some messages & have a wrong group state). - If the message has a "Chat-Group-Member-Removed: member@example.com" header, then remove this member. - If the message has a "Chat-Group-Member-Added: member@example.com" header, then add this member. That means: - Remove checks for the presense of `ContactId::SELF` in the group. Thus all recipients of a message take the same decision about group membership changes, no matter if they are in the group currently. This fixes a situation when a recipient thinks it's not a member because it missed a message about its addition before. NOTE: But always recreate membership list if SELF has been added. The current/older versions of DC don't always set "In-Reply-To" to the latest message they sent (it depends on timings), so we need this heuristic currently. - Recreate the group member list if we don't know the parent (=In-Reply-To) message, even if the sender isn't in the group as per our view, because we missed some messages and our view may be stale.
…3782)(#4624) - If we don't know the parent (=In-Reply-To) message, then completely recreate the group member list (i.e. use the member list of the incoming message) (because we assume that we missed some messages & have a wrong group state). - If the message has a "Chat-Group-Member-Removed: member@example.com" header, then remove this member. - If the message has a "Chat-Group-Member-Added: member@example.com" header, then add this member. That means: - Remove checks for the presense of `ContactId::SELF` in the group. Thus all recipients of a message take the same decision about group membership changes, no matter if they are in the group currently. This fixes a situation when a recipient thinks it's not a member because it missed a message about its addition before. NOTE: But always recreate membership list if SELF has been added. The current/older versions of DC don't always set "In-Reply-To" to the latest message they sent (it depends on timings), so we need this heuristic currently. - Recreate the group member list if we don't know the parent (=In-Reply-To) message, even if the sender isn't in the group as per our view, because we missed some messages and our view may be stale.
…3782)(#4624) - If we don't know the parent (=In-Reply-To) message, then completely recreate the group member list (i.e. use the member list of the incoming message) (because we assume that we missed some messages & have a wrong group state). - If the message has a "Chat-Group-Member-Removed: member@example.com" header, then remove this member. - If the message has a "Chat-Group-Member-Added: member@example.com" header, then add this member. That means: - Remove checks for the presense of `ContactId::SELF` in the group. Thus all recipients of a message take the same decision about group membership changes, no matter if they are in the group currently. This fixes a situation when a recipient thinks it's not a member because it missed a message about its addition before. NOTE: But always recreate membership list if SELF has been added. The current/older versions of DC don't always set "In-Reply-To" to the latest message they sent (it depends on timings), so we need this heuristic currently. - Recreate the group member list if we don't know the parent (=In-Reply-To) message, even if the sender isn't in the group as per our view, because we missed some messages and our view may be stale.
…3782)(#4624) - If we don't know the parent (=In-Reply-To) message, then completely recreate the group member list (i.e. use the member list of the incoming message) (because we assume that we missed some messages & have a wrong group state). - If the message has a "Chat-Group-Member-Removed: member@example.com" header, then remove this member. - If the message has a "Chat-Group-Member-Added: member@example.com" header, then add this member. That means: - Remove checks for the presense of `ContactId::SELF` in the group. Thus all recipients of a message take the same decision about group membership changes, no matter if they are in the group currently. This fixes a situation when a recipient thinks it's not a member because it missed a message about its addition before. NOTE: But always recreate membership list if SELF has been added. The older versions of DC don't always set "In-Reply-To" to the latest message they sent, but to the latest delivered message (so it's a race), so we need this heuristic currently. - Recreate the group member list if we don't know the parent (=In-Reply-To) message, even if the sender isn't in the group as per our view, because we missed some messages and our view may be stale.
…3782)(#4624) - If we don't know the parent (=In-Reply-To) message, then completely recreate the group member list (i.e. use the member list of the incoming message) (because we assume that we missed some messages & have a wrong group state). - If the message has a "Chat-Group-Member-Removed: member@example.com" header, then remove this member. - If the message has a "Chat-Group-Member-Added: member@example.com" header, then add this member. That means: - Remove checks for the presense of `ContactId::SELF` in the group. Thus all recipients of a message take the same decision about group membership changes, no matter if they are in the group currently. This fixes a situation when a recipient thinks it's not a member because it missed a message about its addition before. NOTE: But always recreate membership list if SELF has been added. The older versions of DC don't always set "In-Reply-To" to the latest message they sent, but to the latest delivered message (so it's a race), so we need this heuristic currently. - Recreate the group member list if we don't know the parent (=In-Reply-To) message, even if the sender isn't in the group as per our view, because we missed some messages and our view may be stale.
…3782)(#4624) - If we don't know the parent (=In-Reply-To) message, then completely recreate the group member list (i.e. use the member list of the incoming message) (because we assume that we missed some messages & have a wrong group state). - If the message has a "Chat-Group-Member-Removed: member@example.com" header, then remove this member. - If the message has a "Chat-Group-Member-Added: member@example.com" header, then add this member. That means: - Remove checks for the presense of `ContactId::SELF` in the group. Thus all recipients of a message take the same decision about group membership changes, no matter if they are in the group currently. This fixes a situation when a recipient thinks it's not a member because it missed a message about its addition before. NOTE: But always recreate membership list if SELF has been added. The older versions of DC don't always set "In-Reply-To" to the latest message they sent, but to the latest delivered message (so it's a race), so we need this heuristic currently. - Recreate the group member list if we don't know the parent (=In-Reply-To) message, even if the sender isn't in the group as per our view, because we missed some messages and our view may be stale.
…3782)(#4624) - If we don't know the parent (=In-Reply-To) message, then completely recreate the group member list (i.e. use the member list of the incoming message) (because we assume that we missed some messages & have a wrong group state). - If the message has a "Chat-Group-Member-Removed: member@example.com" header, then remove this member. - If the message has a "Chat-Group-Member-Added: member@example.com" header, then add this member. That means: - Remove checks for the presense of `ContactId::SELF` in the group. Thus all recipients of a message take the same decision about group membership changes, no matter if they are in the group currently. This fixes a situation when a recipient thinks it's not a member because it missed a message about its addition before. NOTE: But always recreate membership list if SELF has been added. The older versions of DC don't always set "In-Reply-To" to the latest message they sent, but to the latest delivered message (so it's a race), so we need this heuristic currently. - Recreate the group member list if we don't know the parent (=In-Reply-To) message, even if the sender isn't in the group as per our view, because we missed some messages and our view may be stale.
Expected behavior:
There are at least a couple ways it could be handled:
Actual behavior:
It creates a major discrepancy in room state between the removed user and all the other users. The deltachat user that was removed continues to receive messages, but cannot himself send anything to the group. Why? His deltachat still only thinks he has been removed from the group. From his own perspective, he does not appear in the group's member list, and thus the text box et al are hidden away.
The strange part is that the other deltachat users in the same group will perceive that he is a member once again. He will appear in the member list just as before. For this reason, he will continue to receive messages from the group, though he cannot respond to them.
Steps to reproduce the problem:
To:
field)The text was updated successfully, but these errors were encountered: