Signup Views

This patch adds the possibility of adding ANY custom field of the signup.theme to the fields list of the view.

Notes:

• When creating the view, you must use the filter "Signup time" to narrow the query.
• Added the anon_mail field
• Polished the Date format for the Signup time.

very cool, thanks to both of you for getting this started! i'm finally using views on a few test sites, and views+cck is clearly the wave of the future, so this is definitely something i want to commit and maintain. however, i'm still learning about views, so it'll take me a little while to review this code, test it out, see if it needs any additional help, etc. for example, i'm pretty sure i'd want to also expose the {signup} table, too, so you could define views/filters on all signup-enabled nodes (not just the {signup_log} table for user's signup replies). however, i'd really have to set it all up and play with it to see how it's all working, and what else, if anything, should be done.

one immediate question springs to mind: where should this code go? here are the choices i see:

1. an obvious answer is in signup/contrib/signup_views/signup_views.moule. for example, that's where location.module puts its views integration code. plus, we've already got a contrib directory started.
2. however, since this is going to be more fully supported than the rest of contrib, i'm tempted to put it in "signup/views/signup_views.module", to make it more of a "first-class citizen" in the signup code base.
3. another approach (which is what OG does, for example) -- don't make it a stand-alone module at all, put it in "signup/signup_views.inc", and automatically include that if views.module is enabled.

the nice thing about option #3 is that the admin doesn't have to do anything special to get it working, and certainly most of the time, if they've got views and signup enabled, they'll want the integration. however, a separate module gives sites the option to leave the module disabled, which would save in code getting parsed on every page load, etc (especially a concern on large sites that are worried about scalability). so, i'm a little torn. votes for any of these options (or alternate proposals) would be welcome.

thanks again!
-derek

in IRC, webchick and merlinofchaos agree: #3 is the way to go. just put it in signup_views.inc and conditionally include it if views is enabled. so, that's what's going to happen once i finally get a chance to look at this more closely and commit it.

+1 for #3
:)

can I assume that this version will also allow the use of a CCK date field and become independent from event.module ? (or is that a separate issue?)

as closely related as views and CCK seem from a end-user standpoint, the changes to the code involved are vastly different. hence, CCK-integration this is a totally separate issue: http://drupal.org/node/86462 (and also http://drupal.org/node/117203 i suppose).

i took the original code, stripped the DOS line endings, applied mariano.barcia's patch, removed a few commented-out lines, turned it into signup_views.inc, and added the code to signup.module to conditionally include it if views is enabled. after light testing, it seems to basically work. ;) cool. however, before i commit and release this, i'd still like to:

• get some input from someone more expert in views...
• add the table and fields from {signup} so you can make views about signup-enabled nodes, not just the signups themselves.
• hear the results of more thorough testing

Great new functionality. Thanks. What about support for displaying registered users' email addresses if the signup was registered? Showing the email address of a registered user is not currently available within Views. Thanks.

Great job!

Though I was kinda hoping there would be a Field [Signup: Count] ... would be very useful for Calendars etc ... :)

here's a more complete version. there are still a few // TODO comments in there for things i'd like to have that aren't quite working, yet (this is my first attempt at views-enabling a module, and some of these are tricky cases). there are no default views defined yet, but i'm nearly done exposing all the fields, filters, etc that i think i'll need. more testing, reviews, and feedback on my choice of UI labels and descriptions would be most appreciated. thanks!

Great stuff dww!

1. SQL Error : if the only Filter set is Signup Enabled/Disabled -> errors :
   * Unknown column 'signup.nid' in 'where clause' query: SELECT count(node.nid) FROM node node WHERE (signup.nid IS NOT NULL) in ...
   * Unknown column 'signup.nid' in 'where clause' query: SELECT node.nid, node.title AS node_title, node.changed AS node_changed FROM node node WHERE (signup.nid IS NOT NULL) LIMIT 0, 10 in ...
2. 'Group multiple values' handler : many of the per-user-signup fields would benefit from the 'Group multiple values' handler to prevent multiple values creating a new table row for each one, eg if you want a table showing all signup events (each in their own row) along with a simple list of the signed up users for each event. It should be easy (for you ;) to copy the code from CCK -> content_views.inc -> content_views_field_handler_group.
3. Field : 'Signup: Email' : could be called 'Signup: Signed up anon' as anon email is the only thing that identifies them as individuals and this pairs nicely with 'Signup: Signed up user'... or keep Email label but also return user (UID) emails ? ... I'm thinking about generating a quick maillist for 'update' emails from the organiser to all the signups ... hmm ... on second thoughts better to do this as a function in signup module so private user data is not exposed.

cool, thanks for the testing. re #3: see http://drupal.org/node/106891 re: #1 and #2: needs work. ;)

I've just noticed that the Field Signup: Signed up user returns 'Anonymous' when there are 0 signups. This is confusing. The odd thing is I didn't notice this before ... so maybe it's something I've caused inadvertently ... if someone could verify this before dww bursts into tears ... ;)

who said i was on the verge of tears? ;) but, now that you mention it, i'm seeing the same thing. it's kind of a tricky bug, so i think i'll need some help from a more views-clueful person to solve it. the query with the LEFT JOIN on {signup_log} that views is building is always returning a row with NULL values. i'm not entirely sure what i'm supposed to do about it -- clearly there's something funky about how i'm defining the tables or fields that's causing the query to be constructed like this, otherwise, it's not clear why views isn't always generating these dummy rows, since it's doing LEFT JOIN by default all over the place.

meanwhile, i fixed #1 completely, haven't looked at #2 at all (we should probably just move to a new issue, in fact), and i fixed most of #3. i also cleaned up the field names i was using to be less wordy and hopefully more clear. i also separated the "Signup: xxx" fields (data about a specific user's signup) from the "Signup settings: yyy" fields (settings about how signups are enabled/configured for a given node). if someone's got any suggestions for better names, just reply here.

as soon as we get the LEFT JOIN stuff figured out, i think this is going to be RTBC. there's *TONS* of views-related stuff i could do, i just want to get the basic fields and filters exported, and then i'll commit this (as the first major new feature for 5.x-2.0, and possibly as a 4.7.x-2.0 backport, if there's enough interest). in the future, we can work on adding better multi-field grouping stuff, default views, etc. i'll even add a Component in this issue queue for views-related stuff.

nice one dww ...

#11.1 - fix confirmed "... SQL errors ... "
#13.1 - fix confirmed "events with 0 signups display 'Anonymous' in the 'Signed up user' field" - or gone away for now at least ... :P
#11.2 - ongoing "Group Multiple Values Handler" I had a look at the code when I was tired and it was a bit more complicated than I had expected ... :( but not impossible :)

#14.1 - "dummy rows" : reference to #13.1 ? ... I'm not sure we're talking about the same thing ?

#14.2 - label suggestions:
Fields:
Signup: User: username
Signup: User: anon mailto
Signup: User: extra info
Signup: User: timestamp
Signup: Node: open/closed
Signup: Notification: mailto
Signup: Confirmation: enabled/disabled
Signup: Confirmation: message
Signup: Reminder: enabled/disabled
Signup: Reminder: scheduled
Signup: Reminder: message

Filters:
Signup: Node: enabled/disabled
Signup: Node: open/closed
Signup: Node: date-range or Signup: User: timestamp ? (definitely needs clarifying!)

Argument:
Signup: User - has signed up for - Nodes
help: Returns a list of all node titles where signups include user (arg=UID).

(it would actually read better if you could defy the module-name-prefix convention and use 'Node: Signups enabled/disabled' and 'User: Signup timestamp' ...?)

Re: the field list that JohnG so nicely put together, just a few comments.

I'd replace the mailto bits with email since the average user will immediately know what that is. I also think the User: timestamp bit isn't the most intuitive, but saying signup time seems a little repetitive, so I don't what is better. Maybe time added? Still seems odd. Other than that the list seems pretty good. More than I would use, but there's no harm in giving lots of choices (unless it makes a list unwieldy to scan through).

As for the module name first, I'd prefer it to stick to convention there. Using the module name first keeps them grouped together in the list and is also consistent with how people expect to find them since that's how others do it (hence the usefulness of sticking to convention).

thanks for FB add1sun :) I agree some of these labels are not quite ... le mot juste ;) It's more difficult than I thought - I'm embarrassed about the amount of time I spent coming up with this list!. I don't mean to imply that the labels list is perfected, but I wanted to point out just some of the factors which IMO should be considered when choosing the labels:

I was trying to balance a number of criteria: 1) make it concise 2) distinguish between sign-up enabled node details and signed-up user 'contract' details, 3) make user intelligible (UI) 'sentences' to suggest how&when each function should be deployed and 4) follow the edit page -> formgroup -> formitem structural logic. Bearing in mind that the person setting up a view of signup fields should be familiar with the signup settings forms labels and layout, a bit of jargon should be permissible.

User: anon mailto & Notification: mailto - we will probably want to add new functions to this list in the future, so it may be useful at this stage to discriminate between 'an email' and an 'email address field', 'email subject field', 'email body field', a 'Confirmation email', a 'Notification email', etc ... I thought the 'mailto' was a pretty neat way to describe an email address ...

User: timestamp - yes a bit technical but it needs to be distinct from any event schedule time stuff, as it represents the system log timestamp for a user submitting a sign-up 'agreement' ... it's not user input data, it is a system log - so it is technical :) ... User: Signup: Timestamp is more logical UI than Signup: User: Timestamp ;)

latest attempt. {signup_log} is always an INNER JOIN (for now), so that you never get records for any of those fields when no one signed up. i may have to revisit this, since i'm going to need a views argument for "all nodes the given user has *not* signed up for".

i folded in most of the field name suggestions, but in a somewhat compromise form. for now, i'm err'ing on the side of more verbose and clear, instead of cryptic and short. i like the 3-tier layout, though, so here's the current list of fieldnames:

Signup: User: Name
Signup: User: Email address
Signup: User: Anonymous email address
Signup: User: Signup time
Signup: User: Additional signup info

Signup: Node: open/closed
Signup: Notification: email address (though "sendto" isn't bad for this)
Signup: Confirmation: enabled/disabled
Signup: Confirmation: message
Signup: Reminder: enabled/disabled
Signup: Reminder: Days before event for email
Signup: Reminder: message

bah! I'll give you cryptic ... just you wait til my neighbour gets his dentist's bill ... ;)

discussed this with dww on IRC. the overall list looks good to me. The only "confusing" bit is the email vs. anon email. It seems more intuitive to me to have one email field and then find Anon people signed up with a filter on username = Anonymous rather than trying to look for users = username and anon = anon email. I know this is bit more work but it would be really, really nice and it won't confuse my site admins as much. :)

Looks good - but I'm a little uncomfortable with exposing the email address of authenticated users to other users. Fair enough - it is down to the discretion of whoever is building the view as to who gets to see this info, if they choose to include it - but perhaps you should put a little warning or caveat in the help text for this field :
Warning! your loyal, caring, regular users might not be too chuffed if you give their email addresses to all and sundry.
or words to that effect ;)

new patch:

• removes the anon email field entirely, since the normal email field works in both cases.
• adds a strong warning in the help for the email field to remind site admins not to be stupid. i'm not 100% sure this is necessary, but i guess it doesn't really hurt.
• adds a filter for if a signed up user is anon or auth.
• adds an option to the signup UID argument handler so you can specify if you want the arg to mean this UID signed up, or this UID has not signed up. woot! this is how i'm going to finally be able to resolve http://drupal.org/node/48267 in the upstream codebase (i've had this on my site for over a year, and it's critical for my needs, but there's never been a really clean, general way to expose the functionality to anyone who wants it).
• following the convention of other views-enabled stuff (e.g. the views support for core modules like node and taxonomy included in views.module), i capitalized more of the field names.

i'll probably commit this to HEAD as-is -- remember, this is only the beginning of views support, not the end. ;) and it's going to be one of the first new features in a (probably fairly active) development series, so it's not like i'm about to freeze any of this code anytime soon.

however, if anyone wants to poke any last-minute holes in this before i commit, speak now. otherwise, you can always open a new issue about it...

i had to re-roll (for the better) due to http://drupal.org/node/134363. committed to HEAD. added a new Component to this issue tracker for "Views integration" -- which is where any further discussion, feature requests, and bug reports should go. ;)

thanks to the greenman for getting this started, and to everyone else who offered input and helped.

The Views-integration is a good first step. What we would really need is a method to export related signup and custom user profile data to a csv-file.

There is a thread in the forums, adrinux described the problem very good: http://drupal.org/node/144839

Open a new issue if you have a new feature request.

is something like this working for signup 6.x or does it have already implemented in main module?
I didn't find any info about this on module page...