Title pretty much says it all. Any thoughts on how this could be possible would be very appreciated.

Currently it seems that this should only be allowed by someone with permission to 'administer all signups', as a way of keeping tack of available and total signups when people register for events by phone, etc.

Because of this, it seems the admin form chould include a toggle between signing up 'Anonymous user', 'Authenticated user', and 'User without email'. This could be a radio select form like $admin_form['signup_usertype'] 

// Allow admin to select Authenticated or Anonymous users to add.
    $useroptions = array('0' => t('Anonymous users'), '1' => t('Authenticated users'), '2' => t('Signup without email'));
    if ($signup_type == 'admin') {
      $admin_form['signup_usertype'] = array(
        '#type' => 'radios',
        '#title' => t('User type'),
        #'#default_value' => '1',
        '#options' => $useroptions,
        '#weight' => -2,
        '#required' => TRUE,
        // Rememeber to add some info for non-js enabled browsers.
        '#description' => $hint .'<div class="js-hide">'. t('Add some info here to show if JS is not enabled in users browser.') .'</div>',
        '#prefix' => '<div class="signup-allow-radios">',
        '#suffix' => '</div>',
      );
    }

This would use js-hide (already used by signup in node form) to allow signing up using one of 3 forms:

1. $admin_form['signup_anon_mail'] (poached from anon_form)
2. $admin_form['signup_username'] (already in admin_form)
3. $admin_form['signup_no_mail'] (new form which just passes the sid and no email or uid)

The admin form validation could validate differently depending on $form_state['values']['signup_usertype']

Does this seems like a possible direction? :)

CommentFileSizeAuthor
#2 349228_signup_without_email.patch6.71 KBscottrigby

Comments

scottrigby’s picture

scottrigby
he/him
Primary language English
Location Brooklyn, NY
commented

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.

scottrigby’s picture

scottrigby
he/him
Primary language English
Location Brooklyn, NY
commented
StatusFileSize
new 349228_signup_without_email.patch6.71 KB

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:

User type: *
(o) Authenticated users
( ) Anonymous users
( ) Signup without email

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!

scottrigby’s picture

scottrigby
he/him
Primary language English
Location Brooklyn, NY
commented
Status: Active » Needs work

Changing status

tlogan’s picture

tlogan commented

Thank you for doing this. It works well.

anders’s picture

anders commented

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?

dww’s picture

dww
we/he/they
commented

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.

anders’s picture

anders commented

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.

scottrigby’s picture

scottrigby
he/him
Primary language English
Location Brooklyn, NY
commented

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

anders’s picture

anders commented

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

anders’s picture

anders commented

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

scottrigby’s picture

scottrigby
he/him
Primary language English
Location Brooklyn, NY
commented

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

cyberswat’s picture

cyberswat commented

subscribing - going to start playing with this tomorrow.

dww’s picture

dww
we/he/they
commented

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?

scottrigby’s picture

scottrigby
he/him
Primary language English
Location Brooklyn, NY
commented

@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?

cyberswat’s picture

cyberswat commented

@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.

dww’s picture

dww
we/he/they
commented

@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.

cyberswat’s picture

cyberswat commented

@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?

scottrigby’s picture

scottrigby
he/him
Primary language English
Location Brooklyn, NY
commented

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?

OpenChimp’s picture

OpenChimp commented

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.

thureb’s picture

thureb commented

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.

joachim’s picture

joachim commented

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

kentr’s picture

kentr commented

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.

joachim’s picture

joachim commented

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.

kentr’s picture

kentr commented

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.

joachim’s picture

joachim commented

#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.

kentr’s picture

kentr commented

@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.

chakrax’s picture

chakrax commented

+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.

awolfey’s picture

awolfey commented

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.

julient’s picture

julient commented

subscribe
They are plenty of cases where someone needs to register someone else who doesn't have an email.
E.g. parents signing-up their kids to go with them to a show. Kids have to be registered so they are accounted for in the tickets logistic, though they don't have an email address.
Has anyone worked on something already? I can chip in if that helps.

awolfey’s picture

awolfey commented

The simple solution here may work. http://www.lullabot.com/articles/user-management-real-world-groups

joachim’s picture

joachim commented

Nice article!

Also, +1 to julient's comment about how common this use case is. It's easy for us to forget that not everyone spends their life on the internet ;)

I wonder if we could add some of Karen's ideas to Signup:

We could have a setting that allows various configurations for email-less singup:

A. allow the person signing up to use just a name instead of an email, with suitable warnings that they will not be able to get notifications. We then create the signup for 'nomail+givenname@mydomain.com in the signup log
B. for signing up several people at once (once we have that feature ;) , require the person doing the signup to have an email, but allow the other people they signup to just have names. Then give them emails primaryperson-secondaryperson@primaryhost.com

ln282’s picture

ln282 commented

I have a solution to the family sign-up issue, but it's an ugly hack. I hope to turn it in to something good enough to share here eventually. If you really want to see it, PM me. From a programming standpoint it's ugly and wrong, but from a usability standpoint, it works pretty well.

When an event organizer sets up a signup on my site, they can define multiple "ticket classes", and decide which ticket classes count towards the sign-up limit (to allow for situations like "lap-children" who don't require a seat, but often need a ticket).

Then members register for the event and claim the tickets their group requires (they can claim multiple quantities of each ticket class). The signup form includes a field to list the names of all registrants. Often the group is a single family, but sometimes one person is the contact for several families. In those situations the registering adult is responsible for passing along any emailed information to the other families. My website is an alternative to the email-based system this community has been using for some time-- having an email-user act as the registering adult for as many people as they choose seems to work well.

My concerns about expecting families to register each member individually:

  • It would be tedious for the member to have to go through the signup process multiple times-- much better to fill out a form once.
  • If the signup is limited, it would be frustrating for the member to have registered only part of the group and then discover that the event is full, and they may or may not go to the trouble of canceling the registrations that went through. (IME, they are likely to fire-off an angry email to the organizer instead)
  • It doesn't allow for a clear single point of contact for the entire family's registration (for example, if the event organizer wanted to contact all the adults attending with lap children, they might be left to guessing which children are attached to which adults-- parents and kids don't always share last names, and some last names are very common).
  • Tracking the group's registration status is going to be tedious and prone to error, because, again, it will be hard to be sure which kids belong to which adults, and therefore credit payment correctly, etc...
  • The organizer is stuck with the responsibility of contacting all of the no-email registrants using another means, which could be a significant burden.

I'm sure there are situations where it makes sense to allow anonymous signups without email, but I don't think the "family with kids" scenario is one of them.

@jaochim -- would option B mean that the primary registrant gets multiple copies of all emails? I recently had a user sign up for 26 people. I think she would have been quite unhappy to receive 26 copies of each email. It's hard for me to imagine a situation where receiving multiple emails would be beneficial. I think it would be much better to somehow put the info for the whole group into a single email.

dww’s picture

dww
we/he/they
commented

I've been too busy with other fires for the past few months to give signup much attention. I haven't really thought much about this issue, but a few quick replies to #31 and #32...

Yes, there are definitely situations where you want a single signup to represent N people, and the "family signup" case is clearly one of them. However, that's really for #45248: Ability to signup for a friend not here. Yes, these two issues are sort of related, but that issue is specifically targeting 1 signup == N people.

So, for this issue, the key point is that people are signing up who don't have an email address. I'm really not sure who these people are who are browsing the web and don't at least have an email address. I think this issue only makes sense if #215211: Admin adding anonymous users to events is finished. It seems this feature is mainly useful for when people contact an event admin out-of-band (phone, in person, whatever) to RSVP an event and the event admin wants to go on the site and signup them up.

In any case, if someone's signing up (or being signed up) and has no email address at all, I don't think giving them a fake email address in the DB make sense. We already get an auto-increment signup ID (sid), so we don't care about a unique key. All anon_mail would matter for is display in the admin UI. It seems basically impossible for signup.module itself to know what fields (if any) you have on the signup form for a given event where truly anonymous signups are possible. Maybe you identify these users by phone number, maybe by full name, maybe by student ID number, who knows... So, I don't think it makes sense to force a particular field in this case and use that for display. if we have an email, we'd store that in {signup_log}.anon_mail so that we can still do email-based features. If we don't, I'd rather that field was NULL in the DB, and I'd be happy if the default admin UI views just displayed signup ID for these people, and sites can customize as needed based on what data they're using...

Hope that all makes sense. I've already had a few glasses of wine tonight and no dinner yet, so I might not be thinking too clearly. ;)

Happy holidays,
-Derek

tborrome’s picture

tborrome commented

subscribe .. need this feature too. need to have anonymous users with no emails to be able to signup up. is this in the latest dev release now?

mradamjohn’s picture

mradamjohn commented

+1 on addressing this feature/issue

amysiano4x3’s picture

amysiano4x3 commented

Subscribe

dooug’s picture

dooug commented

I tried the #2 patch on rc6. It has some issues, but I adjusted it to work for my case. I'd like to see this implemented into the module. If I have time I can try to make a patch against the latest dev.

SeedTreeLLC’s picture

SeedTreeLLC commented

+ 1 and hope it will work with Signup Integration for Ubercart too. I need it for the current site I'm working on.

synthetase’s picture

synthetase commented

Hello, I'm very new to Drupal. I would like to see this functionality. I'm trying to make it easy for users (either patrons or employees at a library) to sign up, often for others, for what are beginner computer classes. Often these people do not have email addresses. I just need the module to generate a list of signups. Requiring user sign in complicates the whole issue. Asking library employees who may not be very familiar with computers to remember an email to put in (or more getting them to grasp the concept of a generic email) isn't really possible. So I'm asking that this please please be implemented in a future release.

Thanks :)

mediarian’s picture

mediarian commented

We need this feature for parents who are signing many small children up for events. Most 2 - 5 year olds who want to register do not have email accounts.

todd zebert’s picture

todd zebert commented

subscribe

todd zebert’s picture

todd zebert commented

What about setting an Attribute as Guests, with options quantity 1, 2, 3 ..... plus the corresponding cost (ticket $ x quantity). It works well enough through the checkout but it's a bit light of a solution when it comes to reporting. I was hoping to use a view to count the Guests but there's no exposed Field for attribute?

Perhaps using http://drupal.org/project/uc_attribute_cck and http://drupal.org/project/computed_field to add http://drupal.org/project/views_attach to expose on the event page? If I get a chance I'm going to try it.

buddakid’s picture

buddakid commented

Subscribe. Some employees are restricted to emails and are not allowed to have email accounts. Supervisors are to sign up for those employees who have user names but not email accounts.