CRM-5905 Adding contact to group via Profile: if CiviMail disabled, contact should be Added without double-optin. If CiviMail enabled, double-optin is used unless disabled in settings file

checked in r -26476.

Found one other bug in this area.... to recreate

1. Set Profile -> Advanced Setting -> Add new contacts to a group = a mailing list group
2. Include a 'required' Email address field in the profile
3. CiviMail is enabled and define( 'CIVICRM_PROFILE_DOUBLE_OPTIN' , 1 ); in settings

When new contact submits profile/create form, they get the message about 'confirmation email will be sent' - and indeed a confirmation email is sent (this is correct behavior). HOWEVER, the contact is added to the Group in 'Added' status. This should be 'Pending' status.

Just upgraded a site from 3.1.3 to 3.1.5 and found that when a user registers for an event where signup page uses a profile that adds user to a group, they now get added with status Pending. CiviMail is enabled. The group is not a mailing group. Is this an unintended consequence of CRM-5905?

I tried adding this to civicrm.settings.php:
define( 'CIVICRM_PROFILE_DOUBLE_OPTIN' , 0 );
as per comment in CRM-4153. This made things worse: the user is now added to the group with status NULL in civicrm_group_contact.

Dave J

Sounds like two issues here based on Dave J's comment...
1. With CIVICRM_PROFILE_DOUBLE_OPTIN false, the group_contact status should be Added, not NULL.

2. I don't think we should invoke the double-optin rules for groups where group_type != Mailing. Let me know if you disagree with this.

In the scenario I described, the user does not get an email inviting them to opt into the group, they just become silently stuck in status Pending.This seems clearly inconsistent: if double opt-in applies to group X then group_contact status -> Pending + email invitation; if not then straight to Added + no email invitation. And I agree with DG above that the double-optin process should only affect mailing groups.

Since "Add new contacts to a group" is kind of admin level feature, i think we should directly add contacts to particular group irrespective of mailing type. Thoughts?

Kurund - We have two use cases here:
1. Profile setting = Add new contacts to group
For this use case, I agree that contact should be added directly irrespective of group type / other configuration settings

2. Group(s) checkbox field in a profile
For this use case, behavior s/b dependent on

• is CiviMail enabled
• is group type = Mailing or not
• is CIVICRM_PROFILE_DOUBLE_OPTIN true or false

Tested on 3.1.6 with following config:

Event E's registration form uses profile P.
Profile P has "Add new contacts to a Group?" = group G.
Group G is not a Mailing List group.
CiviMail is enabled.

Results are the same as in 3.1.5:

(a) CIVICRM_PROFILE_DOUBLE_OPTIN not defined:
Actual behaviour:
When participant registers, they are added to group G with status Pending
Expected behaviour:
When participant registers, they are added to group G with status Added.

(b) CIVICRM_PROFILE_DOUBLE_OPTIN = 0
Actual behaviour:
When participant registers, they are added to group G with status NULL
Expected behaviour:
When participant registers, they are added to group G with status Added.

Expected behaviour is as described by DG in the previous comment:
"1. Profile setting = Add new contacts to group
For this use case, I agree that contact should be added directly irrespective of group type / other configuration settings"

Dave J

Replicated the issue described in my last comment on demo, running rev. 29361: created group, profile & event all called "Test CRM-5905". On registering for the event, the demo user's contact was added to group Test CRM-5905 with status Pending.

This issue is blocking the upgrade of two of our sites from 3.1.3, as we use CiviGroup Role Sync to assign a Drupal role based on the group assigned via profile during event registration.

Dave J,

Can you test with this fix: https://fisheye2.atlassian.com/changelog/CiviCRM/?cs=29498

Kurund

Hi Kurund,

I applied patch 29498 to 3.1.6 & tested as on 26 Aug above. Results:

(a) CIVICRM_PROFILE_DOUBLE_OPTIN not defined:
Actual behaviour = Expected behaviour:
When participant registers, they are added to group G with status Added.

(b) CIVICRM_PROFILE_DOUBLE_OPTIN = 0
Actual behaviour = Expected behaviour:
When participant registers, they are added to group G with status Added.

Also tested using the profile edit form civicrm/profile/edit?reset=1&id=C&gid=G:
Actual behaviour = Expected behaviour:
When profile edit form is submitted, contact is added to group G with status Added.

Good work, thanks!

Dave J

In 3.2.3, testing as above:

(a) CIVICRM_PROFILE_DOUBLE_OPTIN not defined:
Actual behaviour:
When participant registers, they are added to group G with status Removed !?
Expected behaviour:
When participant registers, they are added to group G with status Added.

This is a new version of the problem, haven't had Removed before! Maybe the full fix isn't in 3.2.3 though - it's rev 29586 which therefore I guess includes the merge from 7 Sep above but not the merge on 8 Sep?

Dave J

This needs to be re-verified based on Dave J's latest test results.

Dave J,

I am not able to replicate this issue. Can you provide more details.

Dave J,

Any progress on this ???

Hi Kurund,

Sorry for the delay, have been away. This time, I haven't been able to replicate the problem on either demo or a clean 3.2.3 install, but it still occurs on one of our sites on 3.2.3 . I'll do more investigation ASAP.

Dave J

Closing this issue since I am not able to replicate.