provide default view of available signups (events without a reply)

whoops, minor bug in the previous version of this patch: it used to print this block, even for users that don't have 'allow signups' access. the patch attached to this post fixes this so that the block is only visible if the current user can actually signup for events.

please use this patch instead.

thanks,
-derek

and here's yet another improvement. ;) now, the block doesn't depend on the event module at all. plus, this version notices signup-enabled events of any type. basically, instead of querying all the nodes in the {event} table it now queries all the nodes in the {signup} table (duh). just like the existing "current signups" block, IF the event module DOES exist, then it does the fancy stuff of filtering out events in the past, and ordering the list based on start time. so, other than not being quite happy with the name of the block ("Signups Without Reply" -- i couldn't stomach "Signups Without Signup"), and the corresponding description text ("List of events without signups by current user"), i think this is fully ready to go. let me know
what you think.

thanks,
-derek

looks like you're still restricting the display of the block based on the existence of event module. this is unnecessary now, correct?

ahh, right, where i declare the block up in signup_block(). forgot about that. thanks for catching it.

it would be nice if we could find a shorter admin block description--that one is pretty long.
how about "Available Signups" instead of "Signups Without Reply"? this seems to be more in line w/ the current naming convention

sure, that sounds fine. as i said in a previous post, i wasn't happy with what was there now. on my own site, it's just called "Events without reply", since "Reply" sort of makes more sense for this stuff on my site (where a "signup" could mean anything from definite yes to definite no).

if (! user_access('allow signups')) { i think it would be cleaner to wrap the whole thing in a positive statement, instead of having two return points

that means the entire function has to be nested another level deeper (indented further, etc). reasonable people disagree about what makes for clearer code. i'm of the opinion that highly nested code is worse than multiple return points, so that's how i usually write things. on the other hand, drupal's 2 space indentation convention makes this issue less of a problem. so, if you really want it the other way, you can easily change it when/if you finally commit it to the official repository. ;)

another thought: my query needs a WHERE clause for (signup.completed == 0), or else this will always show non-event signup-enabled nodes, even when signups are closed for that node.

so yeah, code needs work... ;)

but, this is a low priority for me, especially if you're not planning to commit anytime soon. i think we're both more interested in the whole signup plugin architecture. any news on that? (you should reply to http://drupal.org/node/47561, not here...)

thanks,
-derek

clearly, signup isn't going away anytime soon, and this would be useful. since it's just a block sites can leave disabled if they don't want it, there's even less harm adding it to the current code (even in 4.6). therefore, i'm moving this out of postponed, since i'd like to get this updated and committed in the medium-near future. just want to get feedback from others before i commit. also, the existing patch in this thread still needs a little work (see #4), so i'll re-roll when i get the chance. curious what people think of how useful this would be for their sites.

at long last. ;) now that there's view support, we can just provide a signup contrib module (like the views_bonus pack) that defines this block (and a page view, while we're at it) as a default view. ;)

any objections before i commit this to HEAD?

both merlinofchaos and hunmonk would prefer a single, catch-all "signup_views_bonus.module", instead of separate modules for each view. no problem. i'll re-roll in a little while.

ok, let's just put all the default views in a single contrib module: signup_default_views.(module|info).
any other complaints? ;)

this is blocked on:

• http://drupal.org/node/137911 (the cleanup/reorg for signup_no_views.inc)
• http://drupal.org/node/137952 (my new feature for views.module to better handle subtabs)

once both of those land, this will be much better, since we can have:

• user/$arg/signups/current as a default menu tab called "Current", which defines the parent tab called "Signups"
• user/$arg/signups/available as a regular menu tab called "Available"

both of these would be directly in signup_views.inc and enabled by default. (so, we'll put off contrib/signup_default_views for another day once i start adding more crazy default view stuff)...

so, you'd have:

user
| View | Signups | 
       | Current | Available | 

and, of course, blocks you could enable for either/both if you wanted...

bump: http://drupal.org/node/137952 just got committed, so this is only blocked on http://drupal.org/node/137911 (which is itself still blocked on http://drupal.org/node/138217 unfortunately)... but, at least we're starting to see progress again. ;)

yay! merlin fixed the bug in views 5.x-1.6-beta5, so #137911 is no longer blocked. as soon as that's committed, i can quickly re-roll this so it applies cleanly. stay tuned. ;)

this is a patch against signup HEAD with http://drupal.org/files/issues/signup_no_views.patch_6.txt applied from http://drupal.org/node/137911. i think this is the cleanest way to define the view.

Committed to HEAD -- it's about time! ;)