Add multiple invitation email option to the invite form

Hi, very nice feature.
And I must admit I was waiting for it for a while. Can't wait that it get commited.

Here are some remarks about some stuff who need to be improve :
* the labels i.e.
- it is still written "Invite a friend" when it should now be "Invite friend(s)", also it is still written "Type the email of the person" when it should be written something like "Type the emails of the persons" and also "This message will be added to the mail sent to the person you are inviting." should become "This message will be added to the mail(s) sent to the person(s) you are inviting."

The second patch gives me a syntax error when I try to run it.

While the first patch destroy the settings page of the invite module and leaves there only one new field: # invitations. Otherwise, the first patch works.

I have locally made a combination of the two, together with translation patches, based on the latest 4.7.0 version I've downloaded. Attached.

The invite_1.module has '#maxlength' => 1, which doesn't allow multiple email invites. I set it to 2, which then allows setting up to 99 separate email form fields for invitees.

What is needed, I think, is the ability to paste in a list of email invitees in one form field, for "bulk" invitations.

If someone can provide a current, tested and verified patch against the STABLE version i'll see about implementing it.

Please dont mark feature requests as critical.

thanks!

tryed to apply second patch to latest invite.module, but i get following errors when submitting the invitation:

warning: preg_match() expects parameter 2 to be string, array given in /home/kiteatla/public_html/drupal/includes/common.inc on line 635.
Email address is not valid!

invite_1.module at #4 above works fine though

Someone care to re-roll this for DRUPAL-5? If so, I'll commit it.

Hi AjK,
there are quite some issues/feature requests asking for multiple invites.
I have attached a patch for the latest cvs version 5 to start solving the problem.
It does the following:
- Replacing the textfield with a textarea.
- The content of this area is parsed with preg_match_all using the same expression as valid_email does.
- Checking for duplicates.
- Checking if the current invite request exceeds the remaining invitations.
- As well as the pre-patch validations for each mail.
- Finally _invite_send_invite is send for each mail.

Known Issues:
- In case one of the email addresses belongs to a registered user the whole invitation is cancel without identifying the email address that caused the validation failure.

Could you also integrate an option to select the max. number of emails to enter, as done over here?

Also, I fear this won't apply against CVS anymore... I've added the missing 5.x-dev snapshot a few hours ago, it should show up by tomorrow morning.

Apart from that, the code looks solid, will test it tomorrow.
--
Stefan Kudwien
www.unleashedmind.com

Hallo Stefan,
the settings issues shouldn't be a problem. However, i do not quite understand the use of it.
Yes, you're right the patch won't apply. I've just updated my CVS and will supply a new patch within the next days. Hopefully tomorrow.

Viele Grüße

Kai

Hi again,
here is the new patch which should now apply to the current cvs.

Changes:
- Maximum multi invite option. (0=unlimited, 1=disables multiple invitations, ...)
- Settings page now collapsible. (It was way to long IMHO)
- Corrected spelling error "Invite page customization" on settings page.
- new function _invite_get_var_by_role($var_name, [$default, $uid])

_invite_get_var_by_role is a helper function for retrieving role specific variable values. Used for obtaining values for maximum multiple option. This function is able to replace _invite_max_invites_by_role() by calling

$maximum_invites = _invite_get_var_by_role('max_invites', 0);

instead. This is also helpful for future role specific settings.
Testing and feedback appreciated.

Cheers

Kai

Well, at first I felt a bit queasy about letting any users send unlimited batches of emails through my server. But then, this could even be done now with the use of wget, it just requires a bit more knowledge. So the more I think about it, the more I tend to agree with you here. Maybe we should just add a clear warning to the settings page, that the default option of "unlimited" invites per role is a bad decision and could bring you in trouble.

However, there is another flaw in your code: currently, if an email was invalid, a warning will be displayed. Extracting emails using a regexp won't give you invalid addresses, so these will be lost, without further notice. Ie. the following code will never be executed:

    if (!valid_email_address($email)) {
      form_set_error('email', t('The email address @mail does not appear to be valid syntax.', array('@mail' => $email)));
      unset ($emails[$key]);
    }

Since we try to imitate GMail, I took a closer look at how they do it:
- Split email addresses by newlines.
- Send what's valid, display one(!) generic success message.
- Preset the textarea with only the invalid emails and display one(!) generic message to it, stating that these are the remaining invalid ones.

These points sound reasonable to me when dealing with large batches of emails, what do you think?

Cross posting....

Sounds great. I'm on it.

I'm stuck. Can anyone tell me how to get form value past the submit state and into a new form?
Heres my plan.
- split the textarea value in 2 arrays (valid and invalid emails)
- valid emails are processed
- invalid ones are represented (new form? multistep form?)

Can Form API handle this? Could not find anything.
Possible solutions IMHO:
- using variable_get/set to set the textarea default_value (rather dirty)
- using multistep forms and looping them until all emails are valid. (stuck here)

My prefered solution would be to use the validation hook:
Save valid mails in hidden field and reset textarea to remaining invalids. The question is can the user input to a textarea be overwritten in the validation phase? As far as i know form_set_value only helps to transfer values from the validation to the submit phase!?

Hints are greatly appreciated.

You'll want to use $_SESSION['invite_failed_emails'] = serialize($failed_emails); in the validation hook to store the failed emails.

On the invite page, you then just check that session variable, unserialize and unset it accordingly. I don't think the forms API can be used in this case.
--
Stefan Kudwien
www.unleashedmind.com

Removing "active (needs more info)" status to prevent this issue from being filtered away.

Sorry, was busy the last couple of days, but now its all done... i guess. Patch applied. Feedback appreciated.

Just a quick update: I'm testing, I've found some quirks that I'm fixing right now, and I'll post a new patch back.

Thanks.

First, let me say thanks for your great work. Apart from small fixes your patch was working fine. I've simply picked up where you stopped and began reworking the message display, which in turn required bigger changes to the validation hook. Hope you like it, please test and comment back.

Here's what's fixed:

• Added two constants to define the system defaults for max. invites and max. emails per turn to prevent copy'n'paste bugs.
• Didn't like the generic variable getter. However, it lives on as part of the refactored _invite_max_invites_*() functions.
• Messages are displayed through format_plural() where appropriate.

What's new:

• The messages have been generally overhauled.
• The validation hook has been generally overhauled, to be able to efficiently handle error messages for multiple invites.
• There were IMO too much options to choose from, I've reduced them to just 1 (disabled), 5, 10, 100, unlimited

Doh... i didn't know about format_plural() :)
Ok. I have reverted to the latest cvs 5 branch and applied your patch. No problems with that.
Unfortunately all emails are returned as invalid. ...
I'll do some debugging and provide further information asap.

Found the error:
function _invite_send_invite(), line 754:
return $success;
$success is not initialized and not set within the function. Therefore FALSE is returned which causes all emails to be invalid.
return TRUE;
Fixes this problem for me. However, i do not know if that is the way it was meant!?

Full patch.

$success should have been the result from drupal_mail(). Attached patch fixes this bit.

I've just committed the patch from #28, it should be available in both the 5.x-dev as well as 4.7.x-dev downloads within hours. This will hopefully get more people to test the latest changes.

Thanks all, and especially knseibert, for getting this done.
--
Stefan Kudwien
www.unleashedmind.com