Make event signups visible on user registration form

Hi

did a quick check of your patch,
One question, shouldn't form alterations to user forms be made using hook_user(), when $op is "form" (for edits) or "register" (for new accounts).

Also, check at the code I have, this can be integrated with your patch. It presents admins with all open events on user registration form, so they can sign the new user when they create the account.

My sub-module is called signup_af (af for admin form).

/**
 * Implements hook_user().
 */
function signup_af_user($op, &$edit, &$account, $category = NULL) {
  switch ($op) {
    case 'register':
      // Only present if is admin
      global $user;
      $admin = user_access('administer users');
      if ($admin) {
        // Present possible events on registration form
        // Get nodes that are signup enabled and that are still open
        $results = db_query('
          SELECT n.nid, n.title
          FROM {node} n
          INNER JOIN {signup} s
          ON s.nid = n.nid
          WHERE s.status = 1
          GROUP BY n.nid
        ');
        $no_results = TRUE;
        while ($row = db_fetch_array($results)) {
          $no_results = FALSE;
          $events[$row['nid']] = $row['title'];
        }
        if (!$no_results) {
          $form['signup_af'] = array(
            '#type' => 'fieldset',
            '#title' => t('Signup user to:'),
            '#tree' => TRUE,
          );
          $form['signup_af']['nodes'] = array(
            '#type' => 'checkboxes',
            '#title' => t('Available Signups'),
            '#options' => $events,
          );
        }
      }
      return $form;

    case 'insert':
      // Process only if we have results
      if ($edit['signup_af']['nodes']) {
        // Save in our own variable and set to NULL
        // api.drupal.org/api/function/hook_user/6
        $nodes = $edit['signup_af']['nodes'];
        $edit['signup_af']['nodes'] = NULL;

        foreach ($nodes as $nid) {
          // For each node, if has been checked
          if ($nid) {
            // Create signup object
            $signup = new stdClass;
            $signup->nid = $nid;
            $signup->uid = $account->uid;
            $signup->signup_time = time();
            // Save and check result
            $node = node_load($nid);
            if (signup_save_signup($signup) !== FALSE) {
              drupal_set_message(t('User signed up for !node', array('!node' => l($node->title, 'node/'. $node->nid))));
            }
            else {
              drupal_set_message(t('Error signing up for !node', array('!node' => l($node->title, 'node/'. $node->nid))), 'error');
            }
          }
        }
      }
      break;
  }
}

This patch only allows one user to sign up, and then complains that "anonymous" is already signed up for the event. I think you meant
$signup_form['uid'] = $account->uid;
instead of
$signup_form['uid'] = $user->uid;
on line 693.

+++ signup.module	29 Dec 2010 20:47:14 -0000
@@ -662,6 +710,14 @@ function signup_form_alter(&$form, &$for
+/*
+ * Implementation of hook_form_FORM_ID_alter().
+ * Make signup for events visible on the user registration form.
+ */
+function signup_form_user_register_alter(&$form, &$form_state) {
+
+}
+

Needs to be removed.

Powered by Dreditor.

Sorry I didn't look at this earlier. I have some objections. ;)

A) What happens when the signup form has custom fields? Total #fail from what I can see.

B) I don't think everyone creating a signup-enabled node should have permission to inject signup events into the site-wide user registration form.

There might be more, but that's what I noticed on a very quick skim. Drat, now I'm wishing I had made an RC7 not a 1.0 final. ;)

C) I notice y'all added a drupal_alter('signup_user_reg_nids', $nids); but there's no mention of this alter hook in signup.api.php

I don't really regret the 6.x-1.0 release, I was kidding. I just think it's funny that the first thing I did with signup today was create the release, *then* i actually started looking at the code as I was syncing it with HEAD. ;) I'm still big thumbs up on all the effort you spent giving this module some much needed attention!

And yes, we can fix all this in 6.x-1.1... no worries.

This also introduced #1020758: Missing table prefix in query on line 643 of signup.module... ;)

Basically, the lessons for all of us should be:

- We shouldn't commit new features right before a major stable release.
- We should listen to our instincts when thinking another RC would have been a safe bet.

But yeah, none of this is a huge deal. I'm still super grateful for all the work on 6.x-1.0 release, and I'm glad it's finally out, even if it's not perfect (which it's never going to be, anyway)...

The theme function and serialized array in the DB is a nasty hack from the 4.6.x days of signup. However, I think we have different visions about signup data...

You, COD, http://drupal.org/project/signup_profile, etc, appear to think all data belongs in the profile, and the signup is basically just a node reference field for users (to record which nodes a given user cares about). However, in my case (the reason I started using Drupal and why I maintain this blasted module) signups are per-event/per-user meta data. I'm recording stuff like what instrument people are bringing to a gig. That's not something that can be recorded once in their profile. It depends on each user and each node they're signing up for (since I might bring different instruments to different gigs depending on who else signed up, etc). Granted, the implementation for these custom fields currently sucks, and we obviously need much better plumbing for them, but I don't think we should either forget about them entirely, nor say "well, if you really want that stuff, record it in better user profiles".

I think a big part of the problem is that the default custom fields (name/phone) are *exactly* the kind of data that *should* be in your profile, not in the signup (since presumably they're not changing from event to event). But, it's impossible to have reasonable default custom fields which make general sense. Probably it'd be better to have *no* default custom fields, and just have better docs on how to use them. But, I fear if we do that, we're more likely to break the functionality since it'll be out of sight and therefore out of mind.

If I was wearing a COD hat (I won't try to turn that into a codpiece pun -- oh wait, maybe I just did), I could invent a use-case for custom signup fields. Something like if you're planning to record the session with checkboxes for audio, video, note taking, etc. Lots of people attend sessions and record them, and maybe it's nice to get a sense of who's planning to take that level of care. Okay, maybe that's a stretch, but you get the idea, right? Or even something like an "I've got a question I'd like to ask at this session" checkbox. Useful data about the fact that user X is planning to be at event Y, which isn't a property of X nor Y, but of their intersection. Make sense?

Anyway, that's a bit of a digression from this particular patch and issue, but I wanted to clarify why I still care about custom signup data that's *not* in your profile. And that is what you just asked for my input on, so there you have it. ;)

Cheers,
-Derek