Answers.Body: <p>Checkboxes are inherently a confusing html element, because when not selecting them, no value is sent (i.e. not even a null or empty placeholder value). So I can imagine that the core code that this is using is trying to handle that kind of situation from other contexts. </p>
  
  <p>If that analysis is correct, then I suspect the empty box is triggering an unsubscribe, and that unsubscribe is getting merged.</p>
  
  <p>To be fair, in some worlds, that might be the right answer - e.g. if that contact was authenticated when filling in the form, it would be checked, and actively unchecking it should remove the contact from the group. I'd bet you can find an issue of a description like "unsubscribing from a group via a profile not working".</p>
  
  <p>Given your observations, I'd say that an anonymous contact should not be generating those unsubscribes, and if you can figure out where this code happens, it could be improved.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-04-23T20:06:34.140Z
Answers.LastActivityDate: 2019-04-23T20:06:34.140Z
Answers.UserDisplayName: Alan Dixon
Body: <p>When an anonymous user fills out a contribution or other form with a profile that includes the ability to select groups, the user may leave those checkboxes blank, like so:
  <a href="https://i.sstatic.net/Krv8n.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/Krv8n.png" alt="enter image description here"></a></p>
  
  <p>If the anynomous user leaves a checkbox unchecked for a group and that anynomous user is deduped with an existing contact, who is currently a member of the same group, during the processing of the form, then the contact will be removed from the group.</p>
  
  <p>If those groups are used as mailing lists, it is normal for users to leave the box unchecked (as they would not think that they need to check a checkbox to remain on a mailing list they have already signed up for). This is confusing for the user, who unintentionally removes themselves from a group. It is also confusing from the backend as it does not function the same as other fields (e.g. if the user leaves a phone number blank, their phone number is not erased). </p>
  
  <p>This same behaviour is found with a custom field that uses checkboxes or multiselect, while it isn't the same in a custom field using select.</p>
  
  <p>To me, this looks like it isn't the intended behaviour, as it is inconsistent with the behaviour of other fields. Perhaps it has to do with the order in which the deduplication happens relative to the groups. It is also inconsistent with how merging contacts normally works, where groups are added to, but not removed from, the merged contact.</p>
  
  <p>Is this a bug? If it isn't a bug, is there a way to change the behaviour so users aren't removing themselves unintentionally from groups?</p>
  
  <p>I think using a custom field and a smart group would likely solve this problem, but perhaps there is a better way—or this should be changed in general.</p>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-04-17T23:02:20.577Z
Comments.Text: As a smaller point, it is also confusing that the contact record shows that the contact was removed from the group "via web" in this case, as it suggests that it was an intentional act on the part of the contact.
Comments.UserDisplayName: Lars SG
Tags: <profile><groups><duplicate-contacts>
Title: Anonymous user filing out a profile unintentionally remove themselves from groups
ThreadText: # Anonymous user filing out a profile unintentionally remove themselves from groups
  
  (Asked by: username_0 on 2019-04-17)
  
  When an anonymous user fills out a contribution or other form with a profile that includes the ability to select groups, the user may leave those checkboxes blank, like so:
  [![enter image description here](https://i.sstatic.net/Krv8n.png)](https://i.sstatic.net/Krv8n.png)
  
  If the anynomous user leaves a checkbox unchecked for a group and that anynomous user is deduped with an existing contact, who is currently a member of the same group, during the processing of the form, then the contact will be removed from the group.
  
  If those groups are used as mailing lists, it is normal for users to leave the box unchecked (as they would not think that they need to check a checkbox to remain on a mailing list they have already signed up for). This is confusing for the user, who unintentionally removes themselves from a group. It is also confusing from the backend as it does not function the same as other fields (e.g. if the user leaves a phone number blank, their phone number is not erased).
  
  This same behaviour is found with a custom field that uses checkboxes or multiselect, while it isn't the same in a custom field using select.
  
  To me, this looks like it isn't the intended behaviour, as it is inconsistent with the behaviour of other fields. Perhaps it has to do with the order in which the deduplication happens relative to the groups. It is also inconsistent with how merging contacts normally works, where groups are added to, but not removed from, the merged contact.
  
  Is this a bug? If it isn't a bug, is there a way to change the behaviour so users aren't removing themselves unintentionally from groups?
  
  I think using a custom field and a smart group would likely solve this problem, but perhaps there is a better way—or this should be changed in general.
  
  **Tags:** profile, groups, duplicate-contacts
  
  > **Comments:**
  > **username_0**: As a smaller point, it is also confusing that the contact record shows that the contact was removed from the group "via web" in this case, as it suggests that it was an intentional act on the part of the contact.  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2019-04-23. Score: 2
  
  Checkboxes are inherently a confusing html element, because when not selecting them, no value is sent (i.e. not even a null or empty placeholder value). So I can imagine that the core code that this is using is trying to handle that kind of situation from other contexts.
  
  If that analysis is correct, then I suspect the empty box is triggering an unsubscribe, and that unsubscribe is getting merged.
  
  To be fair, in some worlds, that might be the right answer - e.g. if that contact was authenticated when filling in the form, it would be checked, and actively unchecking it should remove the contact from the group. I'd bet you can find an issue of a description like "unsubscribing from a group via a profile not working".
  
  Given your observations, I'd say that an anonymous contact should not be generating those unsubscribes, and if you can figure out where this code happens, it could be improved.
  
  
  ---
  
  