Allow anonymous users to signup

i thought about this feature, but decided against it for a number of reasons. unless enough people step forward and request this feature, or somebody sponsors it and can sell me on why it's an advantage, i don't plan on adding it.

let's see:

• low on the priority list. (you writing a patch would mitigate this mostly)
• counterintuitive, IMO. signing up to an event implies some sort of connection w/ the site that is advertising it
• it's not that difficult or time consuming to create a login. and with jjeff's and my new custom login mod (soon to be released), one step user account creation will finally be a reality. the new forms api might even make it possible to make signup and account creation one step. i don't really see this as a barrier.
• potentially confusing and more difficult to manage anonymous and user signups together. not totally sure about this, but i see it as a potential problem.
• how would you go about retaining the necessary information about for anonymous users? another table? if so, that seems wasteful to me given the point i made above about logins

my feeling now is that i don't want to go the direction of anonymous user signups. i'm certainly open to further discussion on the matter, but i wouldn't accept a patch until this was examined more closely and it made sense to me to put it in.

You're not auto-filling from the user info in any case, so...you just fill in name, etc., and there is no link to the user profile.

ah, yes, but i have inside info. there's a patch in the pipeline that's going to hook signup into the user info... :)

I just looked at your schema. I can see why you don't want to add anonymous :P

lol. yes, it's pretty obvious why... :) but that scheme had advantages--it was quick to build, and it allowed extreme flexibility of the signup form, b/c it's totally themable, although a bit clunky... :) the new forms api should be able to give us the best of both worlds...

I would've probably made email a separate field, and made that the unique key. Every user account must have a unique email address as well, so you can do a join and still get registered member data.

can't make email unique--what if a user signs up for more than 1 event on a site?

you might want to have a look at the README file in CVS. there are a whole lot of potential improvements for this mod already in the pipeline...

Think of signing up for an event. Perhaps your experience is with small sites with a core member base. I'm thinking lots of visitors, most of them anonymous. In fact, I don't care if they ever create an account.

If you don't care if they authenticate themselves, then why are you using the sign up module? :) In its simplest form, even offline, a sign up implies identification and association -- even if its just a signature on a clipboard at the library. I'm curious: what kind of events are you thinking of that would not require identification of a signee?

i just used this module and I think the main problem occurred when people saw that 'login / register to signup'. They thought that registering at the sight was the signup and many have left without actually signing up. So it's also a usability issue too.

oops. I meant site not sight.

as i mentioned above, a one step register/signup form is more than likely possible given the new forms api. that code just hit core, so i'd like to wait a bit until it's stable, then see if that route is possible...

I agree with Chromatic on the usability factor -- I think that a greater distinction between registering as a user on the site and signing up for an event should be established.
Something like, "In order to sign up for *event name*, you'll need to login. If you have not created an account for this site, please click here to create one. " We could also change the workflow so that after creating an account, the user could automatically be taken back to the event and/or process the event signup as well.
We could add this login text description as a field that could be defined as a global and/or individual event setting.

redirecting the user to the event page after they register for a new account is not a currently supported functionality. i'd like my custom login module that i'm building to be able to do this--it's in the works. the best we can do now if we want more seperation is to make that distinction more clear through the help text...

I was hoping to use this for a front page box along the lines of:

"Enter your email address to be notified about new releases ..."

This in turn would generate an email list that I could fire off emails too on an adhoc basis (though usually triggered by a change of a specific node with the new release).

Forcing a signup makes this much less convenient. But otoh, maybe I'm trying to use this for something its not.

Great to see this module exists! Will likely use it for another event-style signup for which its perfectly suited.

mikemee: i think you might want to check out some of the subscription-type mods--i believe they would better suit the need you described.

I think Boris is absolutely right about this. Anon users should be able to sign up. Otherwise, people who visit your site don't see a sign up link and don't realize they can sign up.

The volunteer module allows anonymous signups for volunteers. It's also intergrated with CiviCRM. That would be good for the signup module as well.

Or maybe just adapt the volunteer module for sign ups, and not use signup. There is a bit of rendundancy between the two modules, although they are for slightly different purposes.

anon users will see a link to register/login in order to signup for the event, if the signup perm is enabled for anon users.

so far, i'm not seeing enough compelling reasons to add this feature.

There's a compelling reason from a user perspective. A visitor to your site may care about an event listed on your site, but may not care about your site itself at all. A simple signup form that allows him to be reminded via email of an event he cares about would be better than making him go through the registration/confirmation process for a site he does not care about. There's a difference between the interest in the event and the interest in the site. But of course, and here's the beauty, if a site provides a useful service like allowing him to be reminded of an event he cares about, he might come back and actually register.

the purpose of the module is not to remind users of an event, that's just one of the features. it's purpose is to provide a way for a node to have a kind of one-off subscription to it, and to provide administrators with a way to collect such subscriptions. i believe there is already an event reminder module.

given the module's purpose, i'm still not seeing a clear enough use case for anonymous user signup. if a site had events listed that had absolutely nothing to do with the site--that might be a use case. at any rate, my ears are certainly open--so if i do get a couple of really good use cases that make sense to me, then i can be swayed... :)

of course that doesn't mean that i would actually code it. this module has a laundry list of potential features that could be added, and i consider this one pretty low on the priority list.

Please consider this use case- a kind of 'trial membership' scenario.

I learn about an organisation or service (it may or may not involve a paid subscription), but I want to take my time studying them, analysing how good they are etc., before I commit anything to them- my money, my time as a volunteer, whatever. I then sign up for particular nodes on their web site that match my area(s) of interest/appear most relevant/most interesting/most useful to me. By observing the nodes (and thus, the site/organisation) over a period of time, I am able to take a decision about my involvement with them, at which point, I register for an account.

This could be set by the organisation/site admin also.

I work for a non-profit network that links up non-profits with individuals and corporates- a kind of a collaborative platform. When we talk about the benefits of joining our network, many, many non-profits want to study and observe and then decide. Currently, we use a closed email discussion list based on Lyris for the collaboration stuff and we do have a 'Trial Membership' option where the list administrator can set the term of the membership (set to expire in x months etc.) and also set whether the trial member has read only access or also post to the group. Our experience with the 'trial membership' has been very positive as these members gain an understanding about the way our network functions and invariably go on to become full fledged members.

signup is NOT a node notification module--read comment #17 above for details. the use case you're presenting seems to be for a node notification module.

I didn't mean 'node notification' at all in the use case I presented, but a one-off subscription, as you mention. May be I didn't explain it clearly.

ramdak: the thing that seems missing in your use case is that it doesn't seem to be a situation where event organizers and event participants are getting matched up. that's the direction i've been trying to take the signup module in. it's a bridge to allow organizers and participants to connect via a node. perhaps i should make this more clear in the module description

The very act of identification forfeits your anonymity. It could be three pages of registration data, filled with things like your favourite food and your place of birth, it could be a cookie, it could be your IP for the duration of a session.

These scenarios are all valid concerns and requirements. Unfortunately, not every requirement can be met -- its just not possible -- if you try to incorporate every little feature that everyone wants, you risk "bloating" the core module and even worse, introducing complexity, which makes maintenance and "bug busting" very difficult. Trust me: I've worked on some hideous enterprise applications that look so "feature rich" in the Marketing brochures but cost millions to maintain, by sheer volume of code alone.
Fortunately, the problems described are not that difficult and can be solved in a myriad of ways, which may or not include this module. Here's my stab at summarizing these requirements (feel free to jump in and clarify):

Workflow and usability: "users might not know that they can register...risk losing visitors"

Yup, nobody likes filling out forms. :)
However, this is a simple fix -- Have clear and obvious action items like "Before you can sign up for xyz event, you'll need to create an account with abc.com. Creating an account is easy! All you need is an email address! Click here to create an account now. Concerned about your privacy? So are we. Read our privacy policy to find out the facts". You can define any fields you want for this -- personally, I think email and password is pretty ubiquitous across the Web and shouldn't be a deterent for any user but an email address on its own will work too (something to identify the user).
Put it this way: if your value proposition or trustworthiness is so low that a user isn't willing to provide an email address, then you might have other issues. :)

Authorization: "we want users to be able to create a trial account... "test drive" the site before committing".

This is a really an authorization (permissions) problem. Again, ask for whatever info you want from them -- be it an email address or whatever. If you don't want to collect *anything*, allow anonymous access for whatever nodes you want them to be able to evaluate. Simple.
If you do go the trial registration route, and when that user "converts" from being a trial (or expires or cancels, whatever), you simple change their permissions, preferrably moving them into a different group called "authorized users" or "payed users" or whatever. Then, set group permissions to taste on whatever nodes you want. I used SimpleAccess to do this very same thing.

Another important thing to remember is semantics: you can call it what you want -- I made a clear distinction between "creating an account" (registering) and signing up to avoid confusion but these little details are what makes a site simple to use (think eBay) versus painful to use. Alot of people overlook this and think "its got to be a coding issue -- we need to add feature xyz to fix this..." when using clear language would have much more of an impact on usability.

Identification is the common denominator of community-driven Web sites and this is why the signup module has been written to interact with the core Drupal user model. Without knowing whos-who, you cannot create a meaningful, personalized experience for your visitors.

Hopefully this helps but hey, if you *really* want to hack the Signup module -- giver! Thats the beauty of open source -- write a patch and contribute it. :)

given the module's purpose, i'm still not seeing a clear enough use case for anonymous user signup. if a site had events listed that had absolutely nothing to do with the site--that might be a use case. at any rate, my ears are certainly open--so if i do get a couple of really good use cases that make sense to me, then i can be swayed... :)

This is a very bad attitude for sight growth. I can tell you from experience that online event sign-ups (with the exception of events where tickets are required) are often much lower than the actual attendance. For example, MoveOn.org would hold a vigil, while only 10 might sign up online, hundreds would actually show up. Being forced to register implies a commitment that many don't want to make to RSVP for an event. With sight growth, like organization growth, the key is to set low entry barriers. A quick email sign up, or event RSVP is a good way to do this.

In my political and nonprofit experience, often people sign up, even to volunteer, but don't want to become site members.

On an even more personal note, I bought a product from one site over another today because one forced me to become a member. They had a low price on a product I wanted, but that doesn't mean I want to be a member.

Maybe I'm not making my case all that well, but as a professional organizer, I chose CivicSpace over regular Drupal purely because at the time they had the ability for anonymous sign ups without full site membership.

Quoting hunmonk:

the purpose of the module is not to remind users of an event, that's just one of the features. it's purpose is to provide a way for a node to have a kind of one-off subscription to it, and to provide administrators with a way to collect such subscriptions

Chad - in my mind, you kind of made the argument for anonymous signups which you've been uninterested in, by your statement above. Some websites may have a model where they are publishing information to a group of people. However, the website itself is not an interactive environment that the users themselves participate in. They may particpate in "one-off" events. In this case, one would need to have the ability for these people to signup for these one-off events.

In my case (duplicate posted at feature request 41424), I'm running a "corporate" website, where my site is a publication of information to my users. But my users are not interactive and don't post information. I'm pushing the information at them. I run a sports production event company - we have events that I want users to sign up for, but don't want them having accounts on the system. This is where the anonymous user ability to signup for an event comes into play for me.

Now - if there were some form of workflow combined with the registration process as mentioned earlier in this thread, I might be happy with that. If you could do a simple "3 step" wizard (the workflow part) that walked the user through the quick registration process, and brought them back to the signup page, that would work. But again - I don't care to have my users being active members or accounts on the system. I've worked hard to strip the "community" aspect of the Drupal system off of postings, so it feels more corporate. Having a logged in account changes that.

My model is that logged in accounts are content managers and admins - not my active users base.

THAT BEING SAID - I have already started on coding the anonymous users signup feature. I'm about 1/2 done - most of the "easy stuff" has been completed. As it stands - the anonymous user can signup for an event. Some broken bits I haven't tackled is the email notifications - which are brokend due to the serialized nature of the db table (form_data column in the signup_log table), and the email address being pulled from a logged in users email field.

Attached is my current patch - which is essentially a very rough Alpha quality. I have embedded comments in there that won't be in the final patch, but they are place holder so I know where I"ve been making changes. This is only for those who want to see what's I've done so far - and get any feedback.

Here's a quick set of features:

• added admin setting for "Allow anonymous users"
• added column to signup table to support anonymous user option enabled for a node
• added the allow_anonymous option to various form locations
• added the appropriate db queries for the allow_anonymous option

I have several TODOs to finish this option. In the patch, I've listed my changes with a comment (will be deleted in final patch) with // SYG - so you can search for SYG to find the changes I made. At top of file in patch I have added "SYG TODO" which is a list of the items I have left to fix things to fully get the anonymous users signup option working.

The patch was produced with "diff -u signup.module signup.module.syg" against the 4.6.0 version (1.1.2.9 2005/12/05 17:16:23) module. To apply it, copy the patch into the modules/signup directory, and run "patch -p0 < signup.module.patch".

Feedback welcome.

k, couple of things:

1. if this feature gets added, add it as a new feature for the 4.7 version, not 4.6--since it would require changes to the db table structure. i'd prefer that those be done before i branch for 4.7.

2. i think that adding an option for anonymous signups per node might be overkill--wouldn't it be enough to just add a global option for that?

3. i don't think i want to add captcha support

i'll have a look at this again after you've posted the final patch. if we can keep the implementation light and trouble-free, then i'll probably add it for 4.7

thanks for the work!