attached patch for 4.7 adds support for anonymous users to sign up to events via the signup module. enabling the 'allow signups' permission for anonymous users now injects a required email field into the signup form when an anonymous user visits a signup enabled node. anonymous users who sign up are uniquely identified by the email address they provide. admins have the ability to cancel anon signups. these users will also get confirmation and reminder emails if the node is enabled for those. anon users will not be able to cancel their own signups, use any of the features in the signup_conflicts contrib module, or get a listing of events they've signed up for. following is a summary of the code changes in this patch:
updated the INSTALL.txt and README.txt files to include notes for anon support. added notation to README.txt about signup_conflicts contrib module. removed completed items from TODO.txt. updated signup.install with db changes for anon signups. added conditional inclusion of the event_timezones.inc file (event module no longer includes this file with every page load). eliminated the 'signup' menu callback, and reworked the user signup and cancellation process to be more FAPI compliant. removed the 'email' field from the signup.theme example form--too confusing with the new injection of the anon signup field. reworked signup_conflicts contrib module to disallow support for anon signups.
| Comment | File | Size | Author |
|---|---|---|---|
| #13 | anon_signup_6.patch | 34.54 KB | hunmonk |
| #12 | anon_signup_5.patch | 34.65 KB | hunmonk |
| #8 | anon_signup_4.patch | 34.44 KB | hunmonk |
| #7 | anon_signup_3.patch | 34.24 KB | hunmonk |
| #6 | anon_signup_2.patch | 34.96 KB | hunmonk |
Comments
Comment #1
pjdevries commentedAgainst which version of signup was this patch created? I'm getting quite a few hunks FAILED.
Comment #2
pjdevries commentedPatching against version 4.7 that is:)
Comment #3
webchickHm. Applies fine here. Not had a chance to test it very much yet though.
I'm using // $Id: signup.module,v 1.45.2.13 2006/06/10 03:01:30 dww Exp $ .. make sure you have the most up-to-date version of 4.7 signup module.
Comment #4
hunmonk commentedmy sponsor found a bug in the existing signup code--there was an extra column listed in an INSERT INTO statement, left over from the removal of the permissions column in the signup table. i rolled that simple fix into the patch. he also requested that the anon email field appear at the bottom of the signup form instead of the top, so i've made that adjustment as well. patch attached
Comment #5
hunmonk commentedmore debugging by my sponsor. updated patch corrects:
Comment #6
hunmonk commentedkeeping up w/ latest version of the module.
Comment #7
hunmonk commentedkeeping up w/ latest 4.7, and made these changes to the feature as well:
Comment #8
hunmonk commentedtouching up a couple of things required by the module maintainer...
Comment #9
dwwalong with all the stuff i've mentioned privately, a few more:
should be:
so long as $signed_up_user has both a 'name' and 'uid' field, it works great. this takes care of not presenting the link to users that don't have permission to view user profiles, and makes it easier to theme differently, etc.
<br/>, which the themers don't like. i'd just take all that out, and leave the email address. maybe that email should be a mailto URL?the stuff i mentioned in our latest YIM session should be fixed, too:
<p>from insidet()$needs_signup_form = db_num_rows($result) == 0;for claritybreak;i think that's it. ;)
i'll do a quick review of your (hopefully final) next patch whenever you post it. looking forward to marking it RTBC...
thanks for the good work, hunmonk!
-derek
Comment #10
dwwi learned the secret for db_add_column() working with NOT NULL varchar fields:
instead of this:
you want this:
(note the extra quote marks for the value used in 'default'). then it all works like a charm.
enjoy,
-derek
Comment #11
dwwupon further consideration, my point #1 about
shouldn't be fixed in this patch.
a) it was like that before
b) there are probably a bunch of other places in the code that don't use theme('username') like this.
c) i like to keep individual commits as small as possible.
so, the anon patch should stick to anon (even though it had to move around one of these user links), and we can clean up all the theme('username') stuff in a separate issue.
Comment #12
hunmonk commentedok, attached patch should be the one!
Comment #13
hunmonk commentedhad to make a few small adjustments to fix recent changes to 4.7. this should be it.
Comment #14
dwwlooks great. nice work. thanks for putting up with me. ;)
Comment #15
hunmonk commentedapplied to 4.7 and HEAD. excellent review work--thanks for putting up w/ me... :)
Comment #16
(not verified) commentedComment #17
limex67 commentedIs there still no built-in anonymous signin possible? Do I still need this patch?