Needs to be possible to disable invite code functionality for open sites

The title of this issue isn't clear: I'd label it "Watchdog error: registration code failed".

I think this is the same issue I see: when I manually add a new user via admin > users > add user, I see this error in watchdog: "User username registration code failed" with a Type of "invite". The user is added successfully, but the error is confusing. I'm using 4.7.x-1.2 code.

This same error also appears when a user manually registers on the site.

Hmmm, I'm tempted to say this is should be a "bug report"...not a "feature request"? Maintainers, I'll leave it up to you to change that designation as you see fit. You've been busy in the queue! Awesome and thank you!

That sounds like a bug to me too. Jill, don't be affraid to change the issue status, we don't bite (well, most of us don't) :)

Some thoughts on this.

Even with "open registration" we still need to send the invite code. The reason for this is that several other modules use the invite API to "note when an invatation has been used". Some modules award points to the invitee when the guest signs up. So the invite code is still required.

The "bad invite" error in the log is the real bug here. When I get a chance I'll look into it (unless someone wants to supply a patch ;)

--Andy

Hi AjK,
i'm took a look at it. First thing i noticed is that in version 5 the "invite_only" setting on the user settings page is missing. That is due to a different $form_id value in invite_form_alter().
Patch attached.
Furthermore i think that the watchdog error message should only be generated in case invite_only is set.

What do you think?

- i'm took
+ i took
:)

Ok, just in case that this is the way to go, i have attached a patch (version 5) to do the following:
- check if invite_only is set.
- check if current user does NOT have "administer users" permission.
If both are true generate the watchdog error message. In all other cases don't.

I think the error message only makes sense if invite_only is set. If that is the case administrators should still be able to create users.

Feedback appreciated.

And the patch for 4.7

Thank you, submitted the patch from comment #5 (form_alter id) for the 5.x branch and without the debugging stuff.

The solution concerning the watchdog message is wrong, because when we're in invite-only mode, we'll never get that far: the user will already be blocked before even showing the registration form. A simple if (isset($edit['invite_code'])) solves this issue.

However, a deeper look at the invite module reveals several flaws that need to be addressed, therefore I've chosen to take over the fixing. For example, invitations are never checked if they have expired before accepting a new user registration. And the target roles system seems to be also broken.

I'm currently about to prepare a comprehensive patch that also includes fixes for the issues mentioned above. Would be nice if some of you can help me testing it.
--
Stefan Kudwien
www.unleashedmind.com

Ok, here it is. The list of changes:

1. Prior to accepting a new user registration the invitation is checked that it's not expired.
   • For invite-only sites, trying to register with an expired invitation code should give you a message stating that the invitation code has expired.
2. It was formerly possible to re-use a registration code to register new users with fake e-mail addresses (think of wget). This could be used to illicitly gain points for registrations, for example, when used together with the userpoints module.
3. Registering as new user without an invitation should no more result in a watchdog message claiming that the registration code failed.
4. The old code auto-approved every new user, even when administrator approval would normally be required. This has been corrected to only happen when in invite-only mode (there is currently no such thing like invite-only with additional admin approval requirement).
5. The user escalation ("target role") has been fixed. From looking at the code it looks like it formerly always applied the target role for anonymous users and ignored any other target roles.
6. The invitation code is now generated from user_password(), thus containing a wider range of characters.
7. Updated some descriptions on the Invite settings page that where simply wrong.

Patch for the 5.x branch.

Patch backported to the 4.7.x branch. Untested.

I am using invite-4.7.x-1.2.tar.gz posted on Jan 18, 2007. I applied the above patch for invite 4.7 on my test site. Here is the result:

root modules/invite# patch <invite.module.47.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|Index: invite.module
|===================================================================
|RCS file: /cvs/drupal-contrib/contributions/modules/invite/Attic/invite.module,v
|retrieving revision 1.9.2.20
|diff -u -r1.9.2.20 invite.module
|--- invite.module      16 Feb 2007 02:09:30 -0000      1.9.2.20
|+++ invite.module      18 Feb 2007 23:46:12 -0000
--------------------------
Patching file invite.module using Plan A...
Hunk #1 succeeded at 50.
Hunk #2 succeeded at 92.
Hunk #3 succeeded at 107.
Hunk #4 succeeded at 136.
Hunk #5 succeeded at 155.
Hunk #6 succeeded at 165.
Hunk #7 succeeded at 181.
Hunk #8 succeeded at 197.
Hunk #9 succeeded at 234.
Hunk #10 succeeded at 275.
Hunk #11 failed at 284.
Hunk #12 failed at 536.
Hunk #13 succeeded at 567 with fuzz 2 (offset -4 lines).
Hunk #14 failed at 636.
3 out of 14 hunks failed--saving rejects to invite.module.rej
done
root modules/invite#

I'll attach the .rej file to this comment (renamed to rej.txt as .rej files are not allowed as an attachment type).

ah, I see there is a newer invite module for 4.7.x, invite-4.7.x-1.4.tar.gz, posted on Feb 11, 2007. I'll download this newer version and patch it...and then post back. Thank you for working on this module! It's a keeper.

hmmmm, okay, I patched against invite-4.7.x-1.4.tar.gz dated Feb 11, 2007 (which is listed as the 'official release' at this moment http://drupal.org/project/invite). Here is the result.

root modules/invite# patch <invite.module.47.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|Index: invite.module
|===================================================================
|RCS file: /cvs/drupal-contrib/contributions/modules/invite/Attic/invite.module,v
|retrieving revision 1.9.2.20
|diff -u -r1.9.2.20 invite.module
|--- invite.module      16 Feb 2007 02:09:30 -0000      1.9.2.20
|+++ invite.module      18 Feb 2007 23:46:12 -0000
--------------------------
Patching file invite.module using Plan A...
Hunk #1 succeeded at 50.
Hunk #2 succeeded at 92.
Hunk #3 succeeded at 107.
Hunk #4 succeeded at 136.
Hunk #5 succeeded at 155.
Hunk #6 succeeded at 165.
Hunk #7 succeeded at 181.
Hunk #8 succeeded at 197.
Hunk #9 succeeded at 234.
Hunk #10 succeeded at 275.
Hunk #11 succeeded at 284.
Hunk #12 failed at 536.
Hunk #13 succeeded at 565 (offset -6 lines).
Hunk #14 succeeded at 634 (offset -6 lines).
1 out of 14 hunks failed--saving rejects to invite.module.rej
done
root modules/invite#

Here is the contents of the .rej file

***************
*** 547,566 ****
    return $default_max;
  }
  
- function _invite_role_escalate($invitee) {
-   $inviter_uid = db_result(db_query("SELECT uid FROM {invite} WHERE mid = %d", $user->uid));
-   if ($inviter = user_load(array('uid' => $inviter_uid))) {
-     $roles = user_roles();
-     $targets = array();
-     foreach ($inviter->roles as $key => $role) {
-       $role_no_space = str_replace(' ', '_', $role);
-       if (($target = variable_get('invite_target_role_'. $role_no_space, DRUPAL_AUTHENTICATED_RID)) != DRUPAL_AUTHENTICATED_RID) {
-         $targets[] = $target;
-       }
      }
    }
-   if (($target_role_default = variable_get('invite_target_role_default', DRUPAL_AUTHENTICATED_RID)) != DRUPAL_AUTHENTICATED_RID) {
-     $targets[] = $target_role_default;
    }
    foreach ($targets as $target) {
      db_lock_table('users_roles');
--- 536,551 ----
    return $default_max;
  }
  
+ function _invite_role_escalate($invitee, $inviter) {
+   $targets = array();
+   foreach ($inviter->roles as $role) {
+     $role_no_space = str_replace(' ', '_', $role);
+     if (($target = variable_get('invite_target_role_'. $role_no_space, DRUPAL_AUTHENTICATED_RID)) != DRUPAL_AUTHENTICATED_RID) {
+       $targets[$target] = $target;
      }
    }
+   if (($target_default = variable_get('invite_target_role_default', DRUPAL_AUTHENTICATED_RID)) != DRUPAL_AUTHENTICATED_RID) {
+     $targets[$target] = $target_default;
    }
    foreach ($targets as $target) {
      db_lock_table('users_roles');

okay, back to the download page (view all releases). If I scroll down the page, second from the bottom of the list, I see that there is an even newer release: invite-4.7.x-1.x-dev.tar.gz dated Feb 16, 2007. Wow, y'all been busy!

So I patched against invite-4.7.x-1.x-dev. Here is the result:

root modules/invite# patch <invite.module.47.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|Index: invite.module
|===================================================================
|RCS file: /cvs/drupal-contrib/contributions/modules/invite/Attic/invite.module,v
|retrieving revision 1.9.2.20
|diff -u -r1.9.2.20 invite.module
|--- invite.module      16 Feb 2007 02:09:30 -0000      1.9.2.20
|+++ invite.module      18 Feb 2007 23:46:12 -0000
--------------------------
Patching file invite.module using Plan A...
Hunk #1 succeeded at 50.
Hunk #2 succeeded at 92.
Hunk #3 succeeded at 107.
Hunk #4 succeeded at 136.
Hunk #5 succeeded at 155.
Hunk #6 succeeded at 165.
Hunk #7 succeeded at 181.
Hunk #8 succeeded at 197.
Hunk #9 succeeded at 234.
Hunk #10 succeeded at 275.
Hunk #11 succeeded at 284.
Hunk #12 succeeded at 536.
Hunk #13 succeeded at 571.
Hunk #14 succeeded at 640.
done
root modules/invite#

yippee! Looks like we have a wiener! Ah, lesson learned here: patch version invite-4.7.x-1.x-dev.tar.gz dated Feb 16, 2007.

I'll test the patched module functionality on my live site this week and get back to you (I'm not able to send invite emails from my test bed). Thanks again for all your work.

A small update:
1. I've just committed a patch to prevent the misleading watchdog error: http://drupal.org/cvs?commit=59059.
2. I finally do regret that I captured a rather random thread for announcing a much too large patch. I'm in the process of breaking it down into smaller pieces.
3. This allows me to close this issue.
--
Stefan Kudwien
www.unleashedmind.com