Something that would be really nice is the ability to fetch data from user profile fields, so signup fields would be pre-filled, and users just have to confirm (or change) the data shown.
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | signup.patch | 60.67 KB | gravyface |
Something that would be really nice is the ability to fetch data from user profile fields, so signup fields would be pre-filled, and users just have to confirm (or change) the data shown.
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | signup.patch | 60.67 KB | gravyface |
Comments
Comment #1
IamPter commentedCan you provide an example of what you mean?
Comment #2
gravyface commentedCurrently, the module is making use of the signup_log.form_data field for user registration purposes instead using the users table.
Essentially, all three user fields (Name, Phone, Email) are contained in one big hard-to-read string (a:3:{s:4:"Name";s:13:"My Name";s:5:"Email";s:20:"MyEmail@email.com";s:5:"Phone";s:12:"555-555-5555";}) that gets parsed into an array of field values and printed.
Seeing as registration is required (there's a test for anonymous users on line ~255 which displays the "register/login" link if true), why not JOIN into the user table?
This would reduce redundancy and simplify reusing this data in other/future modules.
I need to get this done for a project I'm working on; I'll see what I can do for a patch, etc.
Comment #3
gravyface commentedSorry, the form_data is getting serialized/deserialize -- my bad. Regardless, I'm almost finished with my modifications and should have a patch available soon.
Comment #4
pieterdt commentedwhat's the status of your modifications? I just saw your post right before i was going to start to make the same changes.
Actually, i think the signup form is not needed. It is only useful when you allow anonymous users to signup. I think it would be better to rely on the profile info of the logged in user, and only show the form for anonymous users.
just my 2 cents. Depending on gravyfaces forthcoming changes i will make some additional ones to allow this behaviour.
grtz,
luksedj
Comment #5
hunmonk commentedyou can't sign up for an event as an anonymous user. the signup form i designed is merely a template--it is not necessary for users to sign up for events, and can be themed so that event coordinators can get any extra information they desire from users at time of signup, or removed completely. there are many other features that could be added to this module(integration w/ user profiles being one of them), but it's not really at the top of my priority list at the moment. by the way, i wouldn't work on any modifications dealing with the signup form right now--the new forms API will be hitting core soon and this will completely transform what can be done in formland... :)
Comment #6
gravyface commentedFinally got the patch finished. Grabbed the latest from CVS tonight and merged my changes with it. Please review this carefully -- this is my first patch. :)
Features:
* implemented seat limits for signup events. Displays "seats
registered, seats remaining" on Signup tab. Default seat limits
(settings > signup) can be overridden on each node.
* added the ability to re-open a closed event from the Signup tab.
* user data is fetched from user table now only. If permitted to
view, anonymous users are now asked to register for a Drupal account.
* "Signup date" is now displayed on signup node if user has already
registered for event.
Bug Fixes:
* user could not cancel signup if the event had been closed; it was
checking if the event was closed first before testing for user
permissions, if user had signed up already, etc.
Comment #7
hunmonk commentedclosing. duplicate issue