tracking actual attendance

currently there's quite a bit of discussion going on regarding major changes in the way event and event-related modules are handled in drupal. my intention is to not do any more major changes to the signup module until those discussions result in a clear course of action. you are of course welcome to hack on your own... :)

there is already a user seat limit patch in the issue queue--check under the 'postponed' status...

i'm co-maintainer of signup along with hunmonk. i'm all about implementing your suggestion #4 (tracking actual attendance). that's something i've been meaning to do for my own site for quite a while. if/when i get a chance to get that working, i'll certainly post a patch for it. it really shouldn't be that hard, i've just been slammed with 1000 other things.

in the mean time, feel free to add any comments to the Events Drupal Enhancement Proposal, especially the Unified support for managing relationships between users and events page.

thanks,
-derek

From the original pile of requests:
(1) is duplicate with http://drupal.org/node/32482, initially released in 5.x-2.1: http://drupal.org/node/142974

(2) is done via http://drupal.org/node/106891, initially released in 5.x-2.0: http://drupal.org/node/137391

(3) could be done via views integration (added by http://drupal.org/node/106808), initially released in 5.x-2.0: http://drupal.org/node/137391

That leaves (4) as the only thing this issue is really about. So, I'm changing the title to be more clear. There's recent interest in this, so hopefully the new title will give it more visibility and someone might write a patch. I'd be happy to have this be part of the main module. This seems like a totally reasonable thing that any event organizers would want to know.

Took a stab at this. Created a signup_attendance table that contains uid and nid to track for attendance. The attendance list is a copy and paste of the 'Signups' list with a checkbox for each row to indicate the user's attendance.

Nothing fancy; reviews?

Cool, thanks for the stab. ;) Haven't tested, but after brief visual skim of the patch, a few questions:

1) Why a whole new table, instead of a new column in {signup_log}?

2) There seems to be no integration with the UI -- you've got a form builder function, but no change to singup_menu() or anything else that renders this form anywhere. And, why bother with a separate form? Why not just modify the existing per-node signup admin form? I'd consider ability to record actual attendance to be a regular signup admin task, not a separate permission with a separate UI.

Please either provide a new patch with the above changes, or explain why you took the approaches you did.

Thanks!
-Derek

dww,

1) Didn't put much thinking into it and just created a new table :P Adding a new column into signup_log works.
2) Whoops, left out the new tab 'Signup attendence' that was supposed to be in signup_menu(). IMHO, managing attendance record from the existing signup admin form might add some complexity to the form given that the admin can already do quite a few things from that form. Nevertheless, I tried going that path and it's not that bad. Now what should the submit button be called since now there are two buttons called 'Update'? It might be confusing to users.

Thanks for moving this forward, definitely getting closer...

If we're going to stick with 2 separate submit buttons, and the 2nd one only updates attendance, it should probably be called something like "Update attendance". That said, this UI *is* getting complicated, I'll admit. ;) It's a weird mix of 3 things:

1) The event-specific table at the top to close/open signups, modify the limit, and view the total.
2) The per-user stuff with a "Cancel signup" button next to each user.
3) Checkboxes for all users, and a single "Update (attendance?)" button at the bottom.

#2 vs. #3 in particular seems weird. Why have per-user cancel buttons, and then a shared update button for all the attendance stuff? On the other hand, canceling a signup is more destructive (there's no undo), so I'd hate to make it too easy to cancel a bunch of signups accidentally while trying to update checkboxes for attendance or something. :(

Anyway, this needs a little more thought. However, I'd really like to deal with attendance on the same page, instead of a whole separate tab just for that.

At the very least, the 2nd update button should be renamed to "Update attendance". For extra credit, maybe it should be rendered inside the table under the column for the attendance checkboxes in a final (otherwise empty) row. Or something. ;)

Also, your patch needs to update signup_views.inc to expose this new data to views before it could be committed.

Thanks, again.

New patch with the following:

1) The submit button to update attendance is aptly called 'Update attendance'
2) The button is rendered in an empty row at the end of the signup list
3) Add a 'No signup details found.' when there are no signups for the node
4) Views integration - Attended field and filter

update 5202 is already taken, but otherwise, this patch still applied. re-rolled for the new DB update. still haven't had a chance to look closely, but i'd like to try to get this committed before 5.x-2.3. stay tuned.

A) signup_install() doesn't define the 'attended' column in {signup_log}, so this patch would only work for sites that upgrade, not new installations.

B) The (11) junk after an int is bogus, and not what you expect, that can be left off completely.

C) 'attended' really only needs to be a single bit. ;) a tinyint/smallint would do, instead of a full int/integer.

No time now for a more thorough review... This might make it into 5.x-2.3, but if not, I'm still definitely interested in getting this in before 5.x-2.4, so don't lose hope.

Thanks,
-Derek

We have an additional requirement for this patch. So, I'm going to look through the current patch to see if we can integrate our requirement. Which, is to have multiple 'status' for each signup. Instead of just one, attended, we also want to list several others. (i.e. new, approved, payed, attended)

I'm posting this message to:
1. give a heads up that someone is doing this,
2. see if anyone is interested in the same,
3. see if anyone has already built such functionality.

peace,
michael

@pelicani: good requirement, wrong patch/issue.
You're either looking for:
http://drupal.org/node/45419
or:
http://drupal.org/project/signup_status

This issue is specifically about storing the simple boolean truth "did they actually show up or not?", which is independent of everything else.

This discussion si far too interesting for not signing me up in it. :)
This is the main reason for this post, but I would like to know if these patches are being added to the CVS version.
Thanks!
Rosamunda

why not just use signup_status and make a status named "actually attended" and once the event happens, move all of those that showed up to that status!

Because you don't want to overload/clobber the actual signup status to record this (what if the existing status is important, even for events that already happened?) and because not everyone wants to use signup_status.

I think that maybe the signup_status functions could be embedded into this module. Yeah, we should avoid using more modules than the strictly needed ones.
But while we wait for that to happen... ;)

Does this patch work with signup 2.4 ?

Just FYI - It looks like this patch doesn't cooperate with the signup_status module as signup_status will replace the main node signup administration form. The option for using both would be to apply the patch code to the form generated by signup_status instead of signup or to just have a second set of statuses with " - attended" for each of the original statuses.

FYI: I'm actively working on this for 6.x-2.* now. The UI I was aiming for ends up not being as slick as I had hoped due to limitations in tableselect.js. So, this is taking a little more effort than I wanted it to. I've got the schema changes done using SchemaAPI, but I need to try a different approach for the admin UI, or just stop using tableselect.js entirely (which would be a little bit of a shame, since it does do a few things nicely).

Anyway, just wanted to let folks know I'm working on a patch, so no one should duplicate the effort...

Ok, here's a patch for the schema update and the UI at node/N/signups. Instead of using multiple checkbox columns, there's now a single tableselect.js checkbox column, a separate column to list the attendance (which you can sort on, and which is just empty if we don't yet know -- although there's a theme function to control what shows up in that column, and of course, it's all wrapped in t()), and then a drop-down selector for the operation you want to perform on the selected users (just like admin/content/node or admin/user/user).

Attached are a few screenshots of the admin UI in action. The only part that isn't done yet is we should have views support for this new DB field, which I'll work on next, but I'd like feedback on the UI and the rest of this patch in the meanwhile.

Here's a patch (depends on #20) that adds all the views handlers for this new DB column. Everything seems to work fine except that the "click sortable" part doesn't seem to be working... Not sure why not.

Greggles pointed out the UI would be more consistent with other parts of core if the drop-down and "update" button were at the top of the table. See attached screenshot.

This patch includes all the views support from #21, too. Still not sure why you can't click to sort on "Attendance" with this...

"Still not sure why you can't click to sort on "Attendance" with this..."

Duh, because I forgot to configure the table style plugin to let this new field be sortable. I suspected it was something dumb like that I was doing. ;) Anyway, #22 should now be really ready to test if anyone else wants to mess with it before I commit.

Just trying this out, but the patch to the signup.install file is looking for a 6200 update to follow on from, but all that's in CVS (on DRUPAL-6--1) is a 6000 update... am I missing a dependent patch somewhere?

Ah, my mistake, I should have been doing it against HEAD instead of 6--1. Now that I've rectified that, it does apply cleanly, and it works well.

Just an edge case, but I wonder if it should also be possible to cancel the 'attendance' status once you've set it? That could be useful in times where the flag is accidentally set for someone who hasn't yet arrived, if it's being updated as people arrive at an event.

Yeah, I guess I can see that. This adds a "Cancel attendance record" operation to the drop-down and code to set the record back to NULL in that case.

I also slightly simplified the queries for the attendance updates -- the sid is unique, so we don't really the nid = %d WHERE clause, we can just use the sid IN (...).

After further discussion with greggles in IRC, we decided this "Cancel attendance record" stuff is way too much of a rare edge case to complicate the admin UI. If someone desperately needs this for some reason, they can touch the DB, but it's going to be so rare, it's not worth it. So, I removed that part again, and committed to HEAD. Yay.

Ok, no problem. It did add a little confusion to the interface, and I can't see it being that widely used, so no big loss :)

FYI: After further consideration, I just backported this (and related changes) into DRUPAL-6--1: http://drupal.org/cvs?commit=159750