Signup anonymous users without email

Ok - I finally sorted out how to do this in a not-too-inelegant way :) yay!

Of course this will have to be totally re-worked after the big changes to signup are made... but still glad to sort out this issue in the meantime.

I had to make a few more changes, and will supply a patch tomorrow after I apply the changes to the current 1.x branch.

Including patch, against current 6.x-1.x-dev.

I'm not sure why, but I had to comment out '#required' => TRUE on $admin_form['signup_anon_mail'] and $admin_form['signup_username']. I am pretty sure I didn't have to do this until the recent changes (though would moving the add form to a subtask change this?), or maybe I'm just overlooking something basic there :p
Isn't it the case that when a required field is hidden using Drupal's js-hide, it is no longer required? Or maybe I'm just wrong about that, and in that case we may need an extra validation on the username (currently it says 'User Anonymous does not have permission to sign up.' if the 'Authenticated users' is selected, and Username field is left blank, which is kind of awkward).

The other thing that I know doesn't work properly is the new JS file js/signup_form.js - this is because I don't know much about JS, and really couldn't find any advice about getting drupal's js-hide to work for three radio buttons. (the top two work, but the third 'Signup without email' doesn't hide the others yet). Here's how it should work:

It should be the case that:
* When 'Authenticated users' is selected, the $admin_form['signup_username'] username autocomplete field displays.
* When 'Anonymous users' is selected, the $admin_form['signup_anon_mail'] email field displays.
* When 'Signup without email' is selected, both 'signup_username' and 'signup_anon_mail' fields are hidden.

Additionally, it would be great if we could specify a default for $admin_form['signup_usertype'] - but I didn't do that because the JS only shows the Username field if you actually click on the radio (for example, even if the 'Authenticated users' is default-selected). I guess this is where JS knowledge would be a plus ;) So any advice about this would be great.

Finally, the last (JS-related) problem I noticed is that any validation errors on the selected Usertypes will reset the js-hide so you have to click the radio button again to see your field. Say for instance you selected 'Anonymous users' but entered an already signed-up email. You'll get the proper validation error, but the field will disappear. Ok, so again - I could really use help with revising the new js file :)

Happy holidays!

Attachment	Size
349228_signup_without_email.patch	6.71 KB

Changing status

Thank you for doing this. It works well.

What is the status of this patch? (what work is needed?) I applied it, and it does work, but some details like the label of the input field and the message about sooe receiving an email needs a bit of care.

Will it be accepted once those are fixed?

The status is that Scott was working on this right as I was trying to get this module ported and stable at all. So, I haven't looked closely yet. He seems to have lost interest/motivation, so I'm not sure what his status is.

In principle, I'm not opposed to this feature, but I really need to look closely at the patch and think more deeply about the problem before I can give any firm answer to "will it be accepted?".

Hope that clarifies, sorry I can't be more specific right now.

I would be interessted in helping a bit if I can, so once you get the time to look it over, maybe I can help out.

@anders & dww: My interest is still there... This patch was initially motivated by a client's request -- and personally my motivation is that it's fun (because Signup module is cool!, and because i'm still somewhat new to the development side of the drupal community).

With the help of Karl (who i work with) we now have a working JS toggle - though it's been a little while, so I'm not sure if the validation issue i mentioned above is solved yet. I'll have to reroll a patch, and will add here soon - maybe someone can give some feedback once that happens.

The client's needs have sort of set our timeline on this feature (this one went on hold while others were worked on). We're solidifying the Signup part of that project over the next few weeks though, so I plan to get back into cleaning-up this and other patches (based on feedback!) and make sure the patches work against the current 6.x-1.x-dev.

One other thought that just popped into my mind -- the label 'Signup without email' should instead be 'Users without email'.

Hi scottrigby,
I'm *very* interrested in testing a patch, and possibly help fixing remaining issues! I'll be looking out for it here.

On a side note, it is silly to name users "Anonymous" when they filled in their name ;)

@anders: I added the JS file to the wrong issue! - try the attachment here: http://drupal.org/node/45248#comment-1234295

subscribing - going to start playing with this tomorrow.

Note: still haven't thought about this much, but it does occur to me that a few signup features assume email -- e.g. signup broadcast, reminder emails, anonymous canceling their own signup (which happens via a magic URL we send them in their confirmation email), etc, etc. It seems potentially tricky to have these features only work on a subset of the users who signup. Obviously, each feature can special-case this and not assume an email, but what happens when an event admin needs to move the location for a meeting, sends a broadcast, but only 3/4 of the users get the email since 1/4 never filled in an email addr?

@dww: good point - i'm not sure if all of those signup features which assume email would need to check first so no errors occur when a signup instance doesn't have an email? That would definitely have to be taken care of.

I was thinking this additional feature really only allows admins to keep track of info about all people who they know are coming to an event even if they aren't email-able (to help prepare for events etc). I was initially thinking this feature would forfeit email notifications for those people an admin signs up without email info.

This just made me think maybe signup_log could keep track of who did the signing up - and allow optional notifications to that person on behalf of all the users they signed up (confirmations, reminders, broadcasts etc) - so that admin can decide to call them or whatever. I'm not sure this is a show-stopper though? I mean, we could just add help text for admins reminding them that "users signed up without email won't receive any email confirmation, reminders or subsequent email broadcasts about this event." What do you think?

@scottrigby It looks like most of your work is focusing on the administrator being able to perform this functionality using the UI ... It seems to me that the best way of approaching this problem is going to be to first focus on the api call and work up to the UI. I think we should figure out a way to change the API in a non-destructive way so that other modules using the signup API would continue to function ... this would require us to first focus on the signup_sign_up_user($signup_form) function.

My initial thoughts are to split the name field out of the form data being stored in the serialized array in the db and turn it into a column in the signup_log table so that it can be used as a unique identifier for anonymous accounts in place of the email address. I'm really hesitant to go down this route to far without feedback from hunmonk or dww due to the fact that these changes would impact the api.

@cyberswat: yes, good point -- we need to start from the plumbing and work up to the sink, not the other direction. ;)

- hunmonk is totally out of the picture for this module at this point. he's moved on to other things. i'm the only one that needs convincing. ;)

- the name field is just an example of the kind of fields you might customize on your site. groups.drupal.org uses no custom fields at all -- there's just a single signup button for the signup form. that's an important use-case to support -- many sites don't need the complication of custom fields at all. so no, there's no chance i'd commit a patch that promotes a name field to first class status as the one true unique identifier for signups to a given node.

@dww I chose name simply because it was a required field in the default installation of the module but wouldn't suggest it become the sole identifier based simply on the fact that authenticated users would use the same mechanism. In the case of g.d.o the signup button seems to require the user to be authenticated providing access to the uid ... is there a use case that would allow an anonymous user to signup without specifying a unique identifier?

Not to put too fine a point on this, but I think the non-email signup feature is only useful -- actually, maybe it's only possible -- for event admins (users with administer signups perms). I don't want to be shortsighted, but I really can't think of any reason why someone other than an event admin would or could use this feature. That said, it seems likely that many event admins would want to be able to use signup to help keep track of all people they think are coming to events (some may register by phone, etc - but still need to be kept track of along with all the other self-signed up users). Please let me know if I'm missing another possible use case.

@cyberswat: All default signup form elements are themeable now (heavily commented at signup/theme/signup_form.inc), and nothing but the signup button is required for the form to work (like on g.d.o - I think this is what dww means). There's now an 'sid' field in {signup_log} as the unique identifier - AFAIK no other identifier is necessary.

@dww & cyberswat: Aside from the few changes I already proposed to signup_sign_up_user() in #2, what else is needed in the API? The only thing I could see that was absolutely necessary to modify in that function was how duplicates are checked.
* Before this patch, the function only checked if it's an anonymous signup (if not, it assumes it's an authenticated one).
* With this patch, after checking if it's an anonymous signup, the function also now checks if it's authenticated: if (!empty($signup_form['signup_username'])) { -- if neither, it assumes a non-email signup. In this new case, it's not necessary to check anything, again because a non-email signup can only be useful as an aid for event admins (no risk of duplicates).

It's true the rest of that patch focuses on the UI for admins (in signup_form.inc, which calls a new js file that's updated in #11). But adding UI isn't putting the sink before the plumbing if we don't need further changes to the API - it's just saying "ok, now that we've got hot water running to the sink, let's add a new fixture so we can use it."

What do you think?

I just want to say that I very much like the idea of providing the admin with the ability to add anonymous users to the signup.

Hope this comment is on the right place.
Our usecase is that members can sign up themselves, signed on and anonymus. People can also sign up via event admin by sending an e-mail, calling on phone etc. This can be for a member or for a nonmember. Not always having a correct e-mail.
Important. Event admin must have the possibility to update the info based on new facts.

Just subscribing and mentioning the existence of this: http://drupal.org/project/visitor which might be worth investigating as a potential API to use.

Another usecase would be a user signing up each of their anonymous guest. A little different than using the "Sign me and x guests up" route.

Someone elsewhere mentioned conferences for doctors who don't have email addresses.
Basically, as soon as we're out of the ecosystem of open source software conferences and camps, we find people who don't have email addresses and don't want the hassle of having to create one -- assuming they'd know where to start.

I want to try to get this into a separate module if it's not going to be included in signup in the near future.

Since I'm not yet very familiar with the API and the Drupal API, input from others would be valuable.

Anyone know offhand if it's impossible or what would be the best avenue?

I'm thinking rather than the options presented in scottrigby's solution, have a single textfield that would attempt to autocomplete on username or email, and then if nothing is found then just use the entered value as an anonymous signup. Hopefully can be modeled after the user reference cck field.

#13:
> but what happens when an event admin needs to move the location for a meeting, sends a broadcast, but only 3/4 of the users get the email since 1/4 never filled in an email addr?

Tough luck for the attendees. It's their choice to sign up without email addresses.
Or, I would say we could require ONE email address / user account per group of singups (the case of the office gopher signing up the whole department), and so there is still one point of contact who would hopefully pass on the information by non-electronic means.

@24- a separate module really doesn't solve anything. Either you'd be duplicating everything here, or you'd still have to make signup work with your new code.

@joachim: You're saying there's no way to use the signup or forms api to add this functionality via another module?

I understand that much / most of what's in this thread would be duplicated. That's the point - to get this code out of "patch" status and into a module so that every new release of signup doesn't have to be re-patched in order to maintain this feature until it's actually committed into a signup release (if ever).

Yeah, it would be great to just get it committed into signup, but since I need something like this soon it for a project that I want to turn over to a client, I don't want them to have to keep re-patching until it gets in.

+1 for not requiring an email id

I have two use cases where an email id is not required. In both cases the pool of potential folks who will sign up are already on an existing email list, and I'm only interested in the list of people who will go to an event. For example - a subset of boy scouts who want to go to summer camp, or who in a group of frisbee players will come to a game. I don't want to force everyone to get an account to be able to sign up for events.

What about a dependent module that would allow users to sign up guests?

- permission based so could be limited to admin roles. (Admin could sign up people who call in, for example.)
- guests- signup data stored in own table, so other email-related functions are not polluted.
- guests signup would add optional fields (phone, address, etc) so guests could be contacted or identified at the event.
- guest might be listed as a column in the signup details form, or in their own rows.

It's possible a client might have me do this, but I'm interested to know if dww and other think this could work in any case.