signup

FYI: I started a ChipIn to raise money to improve the Signup module and port it to D6. The development goals that will be accomplished if we raise the money are: a) drive the CCK integration patch home, b) do everything else needed for a 5.x-2.5 release, and c) port to D6.

My appologises if this has already been discussed but I was wondering if there is a patch (or otherwise) which allows the signup schedule module to more exactly specify the opening and closing time than just midnight on the said day. And if there isn't I was hoping someone would be willing to create said patch as I think it would be very useful for event signups to give more control over the signup period.

I'm thinking about using the signup module for an online class registration process, but I really need a waiting list feature when the classes reach capacity. Has anyone worked on a feature like this, for signup or anything else?

I found one mention of a wait-list feature here: http://groups.drupal.org/node/4151 but haven't stumbled across it anywhere else. Has anyone else had a need for this feature? I'm open to suggestions, or better alternatives than working with Signup, if anyone has any ideas for me.

Thanks!
Jen

I maintain the signup.module. This module has long struggled with the problem of how to flexibly define what fields are requested and/or required when a user signs up for something. I might have a slick solution, but I'm not sure if CCK can accomplish what I have in mind.

With 5.x CCK, you can assign any fields you want in whatever groups you need to any node type. My module could allow site admins to define the signup/reply form for any given node type as a specific group of arbitrary CCK fields. This field group would not show up on the node edit form. It would be displayed on the node view page itself, so each user could fill-in, submit, and optionally edit their own signup/reply. All fields would automatically be treated as "multiples" in terms of storage, 1 set of each field's values per user who replies, but displayed as single values for any given user viewing the node. When a user replies, the values of any fields in their reply would have to be associated with their identity (uid for auth users, email for anon).