New account that need admin approval are immediately subscribed.

This is still the case in 7.x-2.x!

I think having the ability to defer actual subscription would be a pretty powerful feature. I can see jm.federico's use case for doing subscription on user account approval. I have a slightly different use case: I'm using LoginTobbogan to require users to verify their e-mail before getting full access to the site. It would be great to defer list subscription until they actually verify their e-mail, removing the need for Mailchimp's double optin (since Drupal is handling that).

Looking at the code, everything is handled directly in hook_user_insert(). I'm not sure what the right approach is yet, but it'd be cool if there was some way to hook in and setup some custom code to defer the subscription until later. I need to think about it some more before writing a patch.

Comments or advice would be appreciated!

I have an idea about how I could implement this, even in a seperate module (maybe "mailchimp_deferred_subscribe"?):

1. Using hook_user_presave() we could grab $edit['mailchimp_lists'] and stash it in $edit['data'], so that mailchimp_lists_user_insert() wouldn't subscribe the user right away and we'd have the data for later.
2. Then we'd register a new action with the Rules module for completing a deferred subscribe for a user, which would pull the info out of $account->data, actually perform the subscribe and clear out the info in $account->data.

jm.federico would be able to create a Rule that triggered on the event "After saving a new user account" that would cause the deferred subscribe action to happen when the user goes from "Blocked" to "Active" (which is what happens when an adminstrator approves an account).

This would also suit my use case, because LoginToboggan registers a Rules event that occurs when the user has verified their e-mail address.

The one thing I'm worried about is that jm.federico's use case seems pretty basic. I have the nagging feeling that it should probably be supported directly in mailchimp_lists. Requiring another module and Rules seems excessive. On the other hand, for my use case, it seems totally reasonable because it's a more complex/advanced thing to do.

I'd appreciate advice from the mailchimp module maintainers if you have time!

In the D7 version, mailchimp_lists_user_sync() already checks for account status before subscribing a user, so not sure there's an issue?

Other case :

• user subscription is configured to require email verification
• a field mailchimp Subscription is added on user entity, with Double optin unchecked

When user subscribes to the site, he receives a mailchimp confirmation even if he didn't click on email verification link.

In that case, I think that user should not be mailchimp subscribed until he clicked on email verification link, don't you think ?

Subscribe

I had a look at this when faced with this issue on a site I'm maintaing and found what Levelos said in #3 to be true, but not always effective. In this site we've got some logic to automatically block people who sign up with an email domain that doesn't match a pre-approved list of email domains. The account gets unblocked after a site admin contacts them and verifies their contact info.

The issue is that this check fires in hook_profile2_insert, which executes after hook_user_insert, so by the time the user is blocked they've already been added to the cron queue to be synced to mailchimp lists.

This was my quick solution to the problem and is probably too specifically geared to my use case but it might spark some ideas for a more generalised solution that can be enabled with a variable setting.

Here is a patch that adds an extra checkbox to the field configuration to allow you to delay subscription until the account becomes active.

@weseze #7 is that for 2.x?

“And now our watch [for support of the 7.x-2.x version of the MailChimp module] has ended…” With the approaching deprecation of MailChimp’s API version 2.0, I’m sad to say we too must turn the page. This branch will become unsupported in early October and officially deprecated by the end of this year (2016).

Fret not! The 7.x-4.x and 8.x versions come highly recommended. Both are using Mailchimp’s new API 3.0 and are being actively maintained. If you find this issue still exists on either the 7.x-4.x or 8.x branches, let us know by opening a new ticket. “What is dead may never die, but rises again, harder and stronger!”