using signup to track who can not attend, maybes, etc

sorry if my original request was too specific and you're not able to see the value in this feature for other use cases. let me try to be more general. anyone scheduling anything with an online calendar system might want to be able to track 'no' or 'maybe' replies, not just 'yes'. for example, planning parties, organizing volunteer events, rehearsals, performances, art gallery openings, meetings for work, family reunions, political meetings (we can know in advance that we won't have quorum), you name it. in general, scheduling is more complex than just "who can make it?". a definite no is very different from no reply, since it tells the host that a given person cares enough about the event to give you some info, but can't attend themselves. if they don't reply, they might still just show up, whereas if they say they're not coming, you can plan for that. for all of the use cases i described above (and more), this can help the event host decide if they need to reschedule so that more people can attend. RSVP already provides this functionality, it's just completely tied to email, which isn't what i want.

i can understand that you originally intended for the signup module to only support definite yes replies, but i can't see how adding support for other possible replies fundamentally changes the implementation of the module. the patch suggested by kiemce is about 4 lines long to collect the data, and 1 extra field in the signup_log table. while i haven't had a chance to play with it yet, i'm guessing the code to display this extra field when viewing signups will be about another 4 lines. granted, the interaction with the signup conflict stuff might be a little bit more complex, but i can't imagine that's a deal-breaker.

if kiemce and i get this working with a relatively small, clean patch, would you reconsider accepting the patch into the main release? i'd hate to have to keep re-applying (and possibly re-implementing) this functionality for any new release. however, tracking no and maybe is absolutely essential for what i'm trying to do, and it's the primary reason i'm switching to drupal...

if the base module is built on the assumption that signup==yes, i'm not sure how hooks for other modules to interact with signup will be helpful. this seems like a relatively trivial thing for the signup module to do on its own, without the additional complexity of hooks, other modules, etc.

i don't want to come across as being confrontational about this, i think the signup module is great, and i appreciate all the work you've already put into it. i'm just a little disappointed at your initial reply, that's all. :) please let me know if you think this deserves a second look. thanks!

then RSVP is the module you want to work on for this functionality, i believe. if it already does what you need except for web display, then it should be relatively easy to add that to the module.... in this case, it sounds like there's already a module out there (RSVP) who's goal is along the lines of your needs.

well, no. all i was saying is that RSVP (and evite.com, and most other web-based scheduling systems) has the notion that replies can be no, maybe, or yes. that's about all RSVP does that i like. everything else is wrong. ;) it's not just a question of web display, it's that RSVP requires responses via email, separate emails for each event, etc, etc. it's fundamentally the wrong model for what i'm trying to do. signup fits perfectly... there's just a box when logged-in users view a calendar event for them to indicate if they're coming (or not). they can reply in batch by just going through the "Upcoming Events" block. the only problem with signup is that the "or not" part doesn't work yet. :)

try to keep in mind that every line of code that gets added is one i have to maintain as things go forward--i'm sure you can appreciate that that makes me less than cavalier about adding any new feature suggestion...

when i'm not messing around with drupal, my day job is being the core developer (and revision control master) for a huge distributed computing project called Condor. there are about 20 other full-time staff, and roughly 20 students contributing code, not to mention a growing community of folks around the world submitting patches, etc. i coordinate all the branching, merging, who's working on what where, i review the diffs (and tell people what they're doing wrong), etc. so, believe me, i know the pain of maintaining other people's code, accepting patches, and so on. i can definitely sympathize with your situation.

using a well-designed hook system in a module greatly simplifies things in the long run.

i'm so new to drupal that i'll have to take your word on that. in the abstract, that makes sense. i just have zero experience with designing drupal modules + hooks, so this seems more scary to me than a 10 line patch to add support for something that seems so fundamental to an online scheduling system. ;)

keep in mind that the worst case scenario is having to maintain a personal patch for it

right. my years of CVS experience to the rescue if it comes to this. ;) at least i know all about vendor branches and how to use them.

thanks.

i finally had a chance to really understand the inner workings of the signup module (and drupal programming in general). i made an initial set of changes to add the basic functionality i need. i was trying to be general-purpose about it, but some of it is rather specific to the way i've been doing things (e.g. providing a total "attendance estimate", which is the sum of the replies when the responses are normalized to a float between 0 and 1, 0 = no, 1 = yes, .x = some degree of maybe in between). i can fully support *NOT* wanting to apply these exact changes to the main signup module. ;)

i've got my own private cvs repository on my site, where i'm tracking all my changes (not just the signup module, but any configuration, etc... i like to keep *everything* under version control). unfortunately, i just discovered that modules are not strictly versioned like the core (http://drupal.org/node/27362), and the signup-4.6.0.tar.gz you download one day might be totally different than the one you download a day later. :( this makes it a lot harder to use cvs vendor branches to their fullest extent, since i can't just tag an import with the version, i need to use the date, too. oh well, now i know...

anyway, the reason i'm posting again is now that a) i'm really familiar with the signup code and b) i have a working copy that does what i need, i'd like to resume a discussion about how to either implement a hook system that would allow me to add a customized signup_reply.module and/or in some other way fold the useful bits of my work back into the core signup. i still believe most of this would be useful for signup to support natively :) but i can also see that there will be elements of what i'm trying to do which will be fairly specific and that you might not necessarily want to include. my biggest concern about making this modular is that i've added a new field (and have plans to add another) to the signup_log table. that seems pretty fundamental. i suppose i could make a whole new table, also keyed by nid and uid (something like "signup_reply_log"), but that seems somewhat inefficient and more complicated. i guess this comes back to the whole "what's the core, what's a hook?" debate...

furthermore, now that i've checked out a copy of today's 4.6 signup.module directly from the contributions repository, i see that my patch conflicts with a few recent changes you made. :( (2 out of 7 hunks FAILED). so, i'd like to coordinate as closely as possible so that i don't have a major headache trying to keep my changes working relative to the ongoing development of the signup module. of course, i don't need to always update my copy just because you made a change, but clearly it'd be in my best interests to be *able* to use the latest/greatest version you release. i suppose one of my next steps will be importing the latest 4.6 signup module into a new vendor tag, merging my changes into that, and resolving the conflicts. that way, any patches i post will hopefully apply cleanly (assuming nothing else in the module changes in the meantime).

i also have a lot of other ideas of functionality i'm about to add for my own needs. many of these features might be things you'd like the main module to support (e.g. ability for an admin to create signups for other users, edit existing signups, etc), even if you're stuck on the reply-must-be-yes thing. given that my changes are already starting to conflict with yours, i'd like to take a step back and see if we can work out a plan where as much of my work as possible can be folded in (to save you the trouble of implementing it yourself, to save me the trouble of constantly resolving patch conflicts, and to let everyone else have the benefit of the new functionality).

how should we proceed? should we continue to use this issue thread and just keep adding comments? should i upload a giant patch of everything i've done, just so you can see what i've done so far? should i include a few smaller patches of the individual steps i took along the way? should i post a new comment with a detailed prose description of what i changed and why? in terms of new functionality, should i just post new comments to this thread about what i'm planning to do and how? should i start new issue threads about each of them? just let me know what you think would be the most useful course of action.

thanks much, and i'm very excited about working together on this!
-derek

p.s. as soon as i've got all this working to my liking, i've got a few other people eagerly waiting to use my code for their sites, so i know i'm not crazy about how useful this can be. ;)

ugh, that was painful. i just finished importing the 4.6 signup module (as of 2006-01-31) into my local repository and resolved the conflicts. to keep my work more clearly separated for the purposes of this thread, i ended up taking a local workspace of the official 4.6 signup module, applying my patches 1 by 1 (which i originally made relative to signup.module,v 1.1.2.18), resolving problems where hunks failed (relative to 1.1.2.22), and making a new set of patches. luckily, everything appears to still work in my local test site. ;) i'd *really* like to never do this again, but i figured if i'm going to be submitting patches, they should apply cleanly to the current end of the DRUPAL-4-6 branch of signup...

so, now that i went throught the trouble, i'll post 3 more comments to this thread where i'll attach a patch file that applies cleaning to signup.module 1.1.2.22, and i'll paste the cvs log message i used when committing the change to my local repository. these 3 patches build on each other, and should be applied in order. all of them depend on the following change to the signup.mysql file:

diff -u -F^f -r1.1 -r1.2
--- signup.mysql    30 Jan 2006 04:45:00 -0000  1.1
+++ signup.mysql    31 Jan 2006 17:20:16 -0000  1.2
@@ -34,6 +34,7 @@
   uid int(10) unsigned NOT NULL default '0',
   nid int(10) unsigned NOT NULL default '0',
   signup_time int(10) unsigned NOT NULL default '0',
+  reply int(2) unsigned NOT NULL default '0',
   form_data longtext NOT NULL,
   UNIQUE KEY uid_nid (uid,nid)
 ) TYPE=MyISAM;

here's my log message about this:

adding a 2-digit int "reply" field to the signup_log so we can track
replies other than 'yes'.  my current system is using a scale from 0
to 10, where: 0=no, 3=probably not, 5=maybe, 7=probably, 10=yes.
using an int makes it easier to deal with in many places, for
drop-down menus, etc.  however, these values make it easy to print out
the "Attendance estimate" for any signup by summing this value for all
entries that match an nid and then normalizing by dividing by 10.

here's the first patch, that provides the basic changes to collect and display signups with a reply:

cvs log follows, patch attached...

initial changes to use the new 2-digit int "reply" field in the
signup_log so we can track replies other than 'yes'.  my current
system is using a scale from 0 to 10, where: 0=no, 3=probably not,
5=maybe, 7=probably, 10=yes:
- when constructing the signup data-entry view of a node, i added a
  drop-down box for the possible replies.  when we save the values
  into the signup_log table, we obviously include the reply, too.
- if the signup already exists for a node and the user is authorized
  to view signups, this now prints out 2 columns for the signups
  table, Name and Reply.  at the bottom of the table, this also prints
  out the "attendance estimate": (sum of the reply values)/10
- to centralize shared code, i added a private helper method,
  _signup_reply_str() which just returns a string representation of
  the given integer reply value (used both in the dropdown menu for
  data entry and for displaying the replies).

patch #2, fixes the "signups" tab to display replies...

cvs log:

changes to the "signups" tab (the admin interface) to display user
replies.  this now prints two tables, a summary table (with just 2
rows: "Number of replies" and "Attendance estimate"), and the detailed
response table (3 columns: Name, Reply, Other).  in the detailed
table, the username and signup date are printed under "Name", the
string version of the reply (care of _signup_reply_str()) is listed in
"Reply", and everything from the form_data field is under "Other".

patch #3: derek learns about tablesort_sql(). ;) currently only applied to the "signups" tab.

my future plan is to share the code to generate this table between the node view and the signups tab, but to give the signups tab extra administrative buttons for each row (currently only "cancel signup" exists, but i'd like to add an "edit" button to allow admins to change properties of an existing signup, as well as adding an "add new signup" button at the bottom of the table to allow an admin to create a signup on behalf of another user (selecting the user via a dropdown or something)...)

anyway, this is a small diff, since it only touches a few lines from patch #2. as usual, cvs log here, patch attached...

changes to the "signups" admin tab so that the detailed reply table
can now be sorted (default view sorts by reply in descending order, so
"Yes" replies are at the top of the table).

apologies for the typos in comment #10. when i said:

"so, now that i went throught the trouble, i'll post 3 more comments to this thread where i'll attach a patch file that applies cleaning to signup.module 1.1.2.22..."

i meant:

"so, now that i went through the trouble, i'll post 3 more comments to this thread where i'll attach a patch file that applies cleanly to signup.module 1.1.2.22..."

it's late, and i've been working too much today... ;)

it's poised to become a spaghetti mess of code if we don't come up w/ a solid core/plugin approach

thus, i'm postponing the addition of any new features until i've had a chance to think this through and talk w/ some other developers. i've scheduled a meeting at the upcoming conference w/ the co-creator of signup module, and hopefully we can hash most of this out soon.

agreed, i'm all for a core/plugin approach. i'm just going to create a whole new issue thread about that where we can start to get our ideas out there for what the interface is going to be, and solicit input from other signup users and folks with experience in other modules. as i said, i'm not expecting you to apply these patches directly to the 4.6 code. i just wanted to let you see in more detail exactly the kinds of changes i've been making, which will be helpful to think through what a contrib-interface is going to need to do. also, in case anyone else happens to want things to work exactly like i do, they now have the patches to apply for themselves. ;)

moving this out of postponed, since i'd like to consider committing these (or a modification of them) to the real release. however, i'd like to get people's opinions on this stuff, if other people agree this is useful, etc.

Don't have time for the thorough review or any testing now, but hare are some obvious things from a quick skim of the patch:

A) You should merge signup_update_5203 into signup_update_5202 -- there's no reason for separate updates except that's how you developed it on your test site.

B) case 'pgsql':// TODO

C) Do auto-increment fields always start with 1? How do we know after we insert 'Attending' that it's got ssid 1 so that when we alter {signup_log} and use a default of 1, that everything is right?

D) The install sets ssid to default to 0, while the DB update sets it to default to 1 -- this is obviously a bug.

E) Shouldn't "Attending" be inside a t()?

F) In the install/update case, the level for "Attending" is left as 0, yet in the state editing form, the level says "definitely attending" should be a 10...

G) $needs_signup_form = 2; -- if this is no longer just a bool, it should use PHP constants so we know wtf is going on. ;)

H) }; don't need the ; there...

I) $needs_signup_form!= 2 -- code style, needs space.

J) function signup_choice_form() is full of code-style/indentation problems, and is missing its phpdoc comment.

K) '#title' => '', is unnecessary.

L) I thought #type = 'value' was better than 'hidden'.

M) $update ="confirmed."; code style and not translatable.

N) "user chosen status of the subcription" is awkward and needs re-wording to be more clear (if i wasn't exhausted and busy, i'd spend a little time to come up with something).

O) I've never been much of a fan of the extra whitespace in FAPI and menu arrays to make all the => line up, and none of the rest of the module uses that style, so I'd prefer to keep it consistent.

I'll wait for a new patch before I test it closely and review the functionality.

Thanks,
-Derek

Signup status is probably the best solution to this problem at this point. Eventually the right solution will be #29568: Flexible number and type of fields, perhaps after the D7 port where I'd like to make signups field-able via D7 core fields.