Admin adding anonymous users to events

I think adding a new user and signing them up in 1 step is outside the scope of this issue. Sorry I didn't see that in your previous message, but that should really be a separate issue, too. ;) Let's keep this one just about being able to add an anonymous signup. The anonymous signup option is relatively easy and would fit in well with the existing UI. The adding a whole new user thing is pretty far-reaching, and I'm not sure we should support that at all. That's why it'd be good in another issue, so we can discuss the pros/cons of that without delaying the otherwise straightforward feature request in here. Make sense? Thanks.

I found a work around for this anyways. I use the email registration module so all you need to register for the site is an email address. The admin could log out, create a new account for the user if they know their email address and then use the pre-@ part of the email address as the user name to sign them up for the event. Then the user gets emails for a new user account (with password link) and an email about the event.

I've attached a version of signup.module that includes this feature. Creating a patch didn't work correctly because my editing software added a bunch of tabs. I will try to create a better patch (perhaps by hand) and submit it tomorrow.

This version also has an option in the signup advanced settings area to create a user account based on the email entered.

Thanks for taking a stab at this. However, that patch isn't very useful with all the tabs. Please set this back to "needs review" when you have a patch that only touches the lines you changed, and doesn't introduce a bunch of extra whitespace that doesn't follow the coding conventions. Thanks.

I tried to reformat as best I could.

I tried working with the previous patch, but it doesn't apply cleanly and seems to be bigger than what it needs to be.

I've re-rolled the feature as a new patch from scratch. It lets you type in a user name or an email address in the text field, and automatically figures out what you were trying to do. It will not automatically create accounts - that's not something which I at least see as a good feature, at least not unless it's an off-by-default setting.

As well, it breaks out username validation into it's own function, just like for anonymous emails. A new validation function will validate for the field containing a username *or* an email address.

Any feedback is appreciated - let's get this rolled into -dev!

Thanks for rerolling. However, there are some issues in here:

A) Stray dpr() left in the code. ;)

B) Some code style problems (spacing issues, comments that aren't wrapped to 80 chars, formatting of PHP doc comments, etc).

C) Misspelled words in comments.

Lots of those are fixed in my new patch (but not all). However, these are not:

D) I don't like how signup_form_validate_username_or_anon() is getting a $form array by reference and trying to alter the form. That seems like a convoluted hack, to me. There must be a cleaner way to do this.

E) The code adds a comment: // Unset username, move data to signup_anon_mail but I added // TODO huh? at the end of it, since it doesn't look like that's actually happening anywhere. As a result, this code doesn't actually work, and if you give an email addr for an anon signup, the signup is recorded, but the anon_mail field in {signup_log} remains empty.

F) It seems like this "...or anonymous" functionality should only appear if the anonymous user role has "signup for content" permissions in the first place. If a site prevents anonymous signups, I don't see why signup admins should be able to sidestep that restriction.

You're right about the issues - it looks like I uploaded an older version of the code I was working on by mistake :(. So, I've merged in your updated patch with mine. As for D-F:

D) That never actually worked, and I ended up doing the work in signup_form_submit. This means we don't have to do any pass-by-reference like hacks.

E) Yeah, see the _submit function for a set of code which actually works.

F) On the site I'm using now, signup's UI is only exposed to specific users. We're using ecommerce to actually add signups during checkout. However, some orders are still over the phone, so admins need to be able to go in and add users so they can get broadcast and reminder emails. If this is based on a permission, then AFAIK the only way to hide the signup form from users is through the theme, but it means that users could still be evil and send a specific POST?

--Andrew

Just realized I never updated the status on this.

--Andrew

Updated with slightly different description text for the field (added "(if all ready registered)") as it was apparently confusing. Yay user testing!

--Andrew

signup_form_validate_username() becomes an orphaned function with this patch. It's no longer called anywhere, so it's silly to refactor everything like this. A related example: the stuff about form_set_error() vs. drupal_set_message() doesn't make any sense in the new patch. I haven't tested, and I assume this patch actually works, but it makes the code needlessly complicated and harder to maintain. If you want this feature, please reorganize the validation code such that it all makes sense and every line of code is still used for something. ;) Thanks.

Here's an updated patch with the unnecessary functions removed. I'd kept them in there so as to not break other modules calling them using the signup API, so we should be sure to note they changed in the release notes. This should make things a bit simpler.

I would have preferred to simply specify to the Form API that "one of these functions must pass", but it's not possible, hence the creation of the "username or anonymous email" function.

--Andrew

Oh, tee hee, right -- the "signup API". :( Drat, I forgot about that. Hrm, what a pain.
/me needs to think about this a little more.

This is a re-roll of the patch in #9, as that's what I'm currently using. Any thoughts about the API issues?

--Andrew