Details
-
Type: Improvement
-
Status: Open
-
Priority: Trivial
-
Resolution: Unresolved
-
Affects Version/s: 4.7.24
-
Fix Version/s: None
-
Component/s: None
-
Labels:None
-
Versioning Impact:Patch (backwards-compatible bug fixes)
-
Documentation Required?:None
-
Funding Source:Needs Funding
-
Verified?:No
Description
This issue is part of a broader conversation regarding smart groups. See CRM-17257 and CRM-19555 for some companion issues that may be relevant (and were not implemented – the status on the tickets is misleading).
To recreate the issue:
- create a smart group that will include your logged in user
- edit the smart group and mark it publicly visible
- create a profile that exposes groups
- view the profile in edit mode while logged in
Result:
- smart group is displayed but is not checked (logged in user is part of smart group by virtue of the query, not statically added)
- submit the form with that group unchecked. user is not unsubscribed from the group.
The underlying issue/broader conversation is the dynamic where contacts can be part of a smart group through the saved search criteria, but can also be added/removed statically from the group. The issues referenced above discuss some of the challenges holding those two dynamics in tension. I do think there is broad agreement that the static add/remove is widely used and needs to remain supported, though I favor the option discussed in those tickets to make it configurable on a per-group basis.
For the purpose of this issue, I think we do need to address the current behavior on profile forms. As it currently stands:
- a user may visit their profile and get the false impression that they are not currently subscribed to a group
- a user has no ability to unsubscribe from a smart group. this can be done elsewhere – but not through this interface (which is a common way for orgs to expose mailing list subscription options)
I think we need to set the default value on load for both regular and smart groups. Doing so with smart groups will cause a performance hit. However – we could rely entirely on the smart group cache if we want, and even if we need to rerun the smart groups, we would be doing so only for those that are marked publicly visible – i.e. likely a small subset of the total group list. I also think that we should respect the deselection of smart groups and interpret as a static removal.
It would be good to get input/feedback from others regarding this.