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'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

What is the status of this issue with 6.x-xx?

I'm currently only using Signup on a D5 site, so I haven't looked at D6 at all. I'll be glad to update this for HEAD for D5 and D6 pending a resolution about the issues brought up in #12.

Didn't want to hijack this thread for a d6 version so created #426766: Admin adding anonymous users to events- d6

Here's a patch for d6 ... details are in the linked issue

I'm not going to add this feature (and potentially change the API) in the D5 version unless someone hires me to do so. ;) This issue should be for changing this in D6. Thanks.

The really interesting thing about this problem is the core definition of what an anonymous user is. The patch I submitted earlier meets the needs of the original poster of this ticket. However, the assumption of the signup API is that even though a user is anonymous they will have a unique identifier of an email address. The client that we are doing this for pulled out all the stops by mentioning that their staff should be able to enter a signup on behalf of attendees that physically call in their signup request. These attendees are likely calling in because they do not have a computer or an email address. I was shocked to learn that these types of people still exist ;)

Allowing an admin to use the existing framework to enter a user with an email address but not a user account is a minor fix. Allowing an anonymous user to exist without an email address is a potentially significant API change.

edit - I point myself to #349228: Signup anonymous users without email

At the organization I deployed signup for, we came into the same issues with individuals possibly not having email addresses. While this was a concern, even the people calling in seem to have email addresses, and in practice it hasn't been a problem.

IMO requiring at least an email address is an acceptable requirement of the feature.

@deviantintegral I can understand your perspective on the issue as it is the one I had before speaking with our client. However, our clients target audience for events includes people that do not have an email address. It would be a shame to not be able to take advantage of the work done on this module because of this and I don't want to put the client in a position where the end up with a fork that does not have an update path. The patch attached to this issue for 6 requires the email address. Lets pull the discussion about if that is a sound choice over to #349228: Signup anonymous users without email

@mdowsett In the use case you describe the administrator is given a message that the email in question already exists on the site utilizing the modules anon validation that was in place before the patch. That behavior is not touched by what this patch introduces. The method that is currently in place gives the administrator the ability to react in the way that they say fit for their system. They would then have the option of creating the user account themselves and signing up the account on the users behalf, they could create the account and educate the user how to sign-up, they could do nothing at all or any number of things I'm not thinking of. I think by leaving these as choices the administrator can make when they get this message using the existing tools will let us keep this patch as simple as possible increasing the likelyhood of it being accepted.

I made a few alterations post-allowing-anonymous-users-to-signup patch to include the ability to specify this on a per-node basis. In my installation, some events might be for all, and some just for registered users. With the attached, I've been able to achieve that. Note that this patch is against the patched 5.x-2.7 version. Someone might find it useful...

On a side note, why do versions sometimes get unilaterally changed on issues as opposed to starting a new issue with a new version number. This did indeed start out as a 5.x issue. Makes things hard to find if version numbers get changed like that, IMHO.

shawn

"why do versions sometimes get unilaterally changed on issues as opposed to starting a new issue with a new version number"

Because I maintain this module, and I can make unilateral decisions like "I'm no longer adding new features to the 5.x version". ;)

Also, having multiple issues to discuss the same feature makes it harder to find and follow the discussion than having a single issue that covers the lifetime of the request, regardless of which version(s) it's referring to...

Cheers,
-Derek

Well, sure, I guess that's your prerogative. Sometimes I wonder if there's a better way. I'm sure few care about my patch or that functionality, but it's interesting to note that i almost gave up posting it as it took me so long to find the original thread...

shawn

Here is an updated version of the patch from #17. It adds some jQuery to only show the username or the email address, since only one is required.

The patch otherwise still seems to work fine.

#26 applies cleanly, and it works. Patch mostly looks good on visual inspection. Two issues, not sure what I think:

A) Seems slightly weird that the form has either $admin_form['signup_attendee']['signup_username'] or $admin_form['signup_username'] depending on if anon can signup or not. Perhaps it'd be better to just always use $admin_form['signup_attendee']['signup_username']? Seems that'd make it easier for altering, etc.

B) Completely unhelpful, but I found the JS version of the UI a bit confusing and slightly unattractive. Not sure what to suggest instead, but it just doesn't feel right. Sorry that's such sucky feedback, but that's all I can muster. ;)

Can't bring myself to set this to "needs work" based on such vague concerns. Anyone have any thoughts or suggestions?

Thanks!
-Derek

p.s. This is a small enough change I wouldn't mind sneaking this into RC5 or 6.x-1.0 official, so I'm leaving the version at 6.x-1.x-dev instead of bumping to 6.x-2.x-dev.

I agree on a consistent form array structure regardless.

I didn't test out the javascript technique, but the description of the way it works seems weird. BTW, when you post a UI changing patch a screenshot is really helpful.

confused.. I am running rc4 and would like to test/use anonymous sign-up using email entered from visitor. I see in my permissions a check box for anonymous user sign-up, but it doesn't seem to do anything.
Is anonymous user sign-up rolled into the .dev? Do i need to run .dev and add a patch, if so, which patch should i use/test..
thanks, dave

editing.. I must be stupid today.. just realized it only shows on full node, not teaser.. sorry..

dbeall: That's a separate issue. This is just about the ability for admins to manually add anonymous signups. Yes, RC4 supports anonymous signups just fine. You have to give anonymous users permission to signup, then log out of your site to see what anonymous users see. ;)

Subscribing

Subscribing. I just received a request from a site owner who gets older event attendees who don't use the Internet and call their reservation in.

what's the status of this? can the admin user now add signups for anonymous users without requiring usernames or email addresses? is this in the latest signup dev release?

I really need this - would it be better to leave both fields showing and omit the JS tricks.

subscribe - looking for admin add signup non-user using just email (or perhaps also name only without email).

We are running 6.x-1.0-rc6 and need this. What is the status on this functionality?

I don't think it makes sense to limit the event admin from adding anonymous users if anonymous users themselves are not allowed to sign up. If the event admin is given the permissions to admin the event, I think they should be able to do what they want. Disallowing anonymous users themselves is a different thing..

This doesn't seem to play nice with signup_confirm_email, as that module injects the current users email address into this form as a separate field.

Rerolled patch and removed the check for anonymous access to signup (see comment #37).

Just my take on it...

Edit: forgot to remove a dsm() - new patch coming.

Fixed patch

Edited to note: I had previously thought I'd encountered an error introduced by this patch - but after further testing, it looks like the bug exists in an unpatched version as well - sorry!

I really need to be able to have a member sign up for anevent with 1-3 guests who are not members - is there a way to do that?