How to list all signed up users in a view??

Given how views1 works, this is really hard. You're really trying to make a view of users, not nodes, and views1 doesn't handle that. views2 will make this trivial. Meanwhile, you're pretty much out of luck. I'm not sure it'd even be possible to make this work in views1. The only way it *could* work is if you were using a users-as-nodes solution, and signup had a way to map signup users to their corresponding nodes. :(

Actually, you can do this in views1. Sorry about the confusion. Here's the view that's used on groups.drupal.org for the "Attendees" tab on event nodes:

  $view = new stdClass();
  $view->name = 'signup_event_attendees';
  $view->description = 'List all attendees.';
  $view->access = array (
  0 => '2',
);
  $view->view_args_php = '';
  $view->page = TRUE;
  $view->page_title = 'Attendees';
  $view->page_header = '';
  $view->page_header_format = '1';
  $view->page_footer = '';
  $view->page_footer_format = '1';
  $view->page_empty = 'No attendees yet.';
  $view->page_empty_format = '1';
  $view->page_type = 'table';
  $view->url = 'node/$node-event/attendees';
  $view->use_pager = TRUE;
  $view->nodes_per_page = '200';
  $view->menu = TRUE;
  $view->menu_title = 'Attendees';
  $view->menu_tab = TRUE;
  $view->menu_tab_weight = '2';
  $view->menu_tab_default = FALSE;
  $view->menu_tab_default_parent = NULL;
  $view->menu_tab_default_parent_type = 'tab';
  $view->menu_parent_tab_weight = '0';
  $view->menu_parent_title = '';
  $view->sort = array (
    array (
      'tablename' => 'signup_log',
      'field' => 'signup_time',
      'sortorder' => 'DESC',
      'options' => 'normal',
    ),
  );
  $view->argument = array (
    array (
      'type' => 'nid',
      'argdefault' => '1',
      'title' => '',
      'options' => '0',
      'wildcard' => '',
      'wildcard_substitution' => '',
    ),
  );
  $view->field = array (
    array (
      'tablename' => 'signup_log',
      'field' => 'uid',
      'label' => 'Username',
    ),
    array (
      'tablename' => 'signup_log',
      'field' => 'signup_time',
      'label' => 'Time signed up',
      'handler' => 'views_handler_field_since',
    ),
  );
  $view->filter = array (
  );
  $view->exposed_filter = array (
  );
  $view->requires = array(signup_log);
  $views[$view->name] = $view;

Feel free to give that a try, and let me know if it's working for you, too. If so, I could add something like this as another default view provided by signup.module.

Cheers,
-Derek

subscribing

Due to a limitation in how views works, this won't be perfectly slick just from the views UI. The problem is that we only want this tab on signup-enabled nodes, and there's really no way to specify that with the views UI itself. So, I think we're going to need a wee bit of custom menu code in signup_views.inc and a few settings to control this menu item. It'll just render the view you still define with the views UI, but you don't want to specify it as a menu item via the views UI. I'll take a quick stab at this and see how far I get.

Work-in-progress, still needs some work, but this is the basic idea. You can use it with the exported view attached with the patch. I'm convinced there's gotta be a better solution for this, but that'll require some input from the views gurus.

Yay! As hoped, merlinofchaos provided a viable solution to this via the views API: hook_views_url_tokens(). So, we can just define a $signup URL token, that will match with any signup-enabled node. Then, the URL for this view can be something like node/$signup/signup-list, and it'll all work as expected without any of the previous custom menu code. phew!

FYI, there is an issue with breadcrumbs and that technique. see http://drupal.org/node/183191

I've implemented a patch which uses the views API as suggested. I've also attached a slightly modified view that includes a menu tab, and sets the view title to that of the node. It's working as expected on my test site, only showing the menu tab on signup-enabled nodes.

--Andrew

Thanks, that was a great start. I rerolled for the following:

A) Tweaked the default view for this (made both fields sortable, removed the CSV view arg since views bonus can't be assumed, capitalization of the menu item, etc) and added it to _signup_views_default_views().

B) Removed the unnecessary patch against signup.module that was a hold-over from the previous attempt.

C) Made the code that manually displays the list of users signed up for a node into a theme function, theme_signup_user_list(). Otherwise, if you turned on this view, there was no good way to disable the hard-coded display of this info.

However, I've got a few questions about (C) for consideration before I commit this:

C.1) Currently, I put the logic to query the DB into the module code and the theme function just formats/displays the results. Normally, that's good in the separation of logic and presentation sense. However, in this case, one of the most common implementations of the theme function will become return '';. ;) So, it's dumb to do the 2 DB queries if we're not going to display any of the data, anyway. Should I move the queries into the theme function?

C.2) Should I move the theme function into the signup_no_views.inc world and if views is enabled, don't invoke the theme function at all and have the "Signup list" tab appear by default? Currently, that view is disabled by default.

Any thoughts on the best approach here would be welcome. Thanks!
-Derek

Re C.1): I don't see where it returns an empty string. If a user doesn't have the proper permissions the function is never called. If you have the permission to view all signups it always return a table with at least one row of data.
So I think there is no need to move the queries out of _signup_node_output.
Or am I watching the wrong lines?

To clarify: we are talking about these lines:

    $registered_query = db_query("SELECT u.uid, u.name, s.signup_time, s.form_data FROM {signup_log} s INNER JOIN {users} u ON u.uid = s.uid WHERE s.nid = %d AND u.uid <> 0", $node->nid);
    $registered_signups = array();
    while ($signed_up_user = db_fetch_object($registered_query)) {
      $registered_signups[] = $signed_up_user;
    }
    $anon_query = db_query("SELECT * FROM {signup_log} WHERE nid = %d AND uid = 0", $node->nid);

I'm some kind of confused now :-)

(I know I said I was going to bed, but I'm still wrapping up a few things and noticed this comment...) ;)

What I meant with the reference to return ''; is that, given patch #9, any site running views (the vast majority) that wants to use this view for the signup user list instead of the hard-coded stuff is going to want to put this in their copy of template.php:

phptemplate_signup_user_list($registered_signups, $anon_signups) {
  return '';
}

In other words, completely remove the table, since we've already got the signup user list on another tab (or wherever the admin puts it) thanks to views.

Make more sense? In this (IMHO very common use case) that means we're doing these two extra queries for nothing (except the feeling-good-about-ourselves-for-not-putting-SQL-in-theme-functions beauty of the code).

So, this makes me think we need something else that decides if we even want to invoke this code at all:

- if (module_exists('views')) { ... }
- a setting at admin/settings/signup
- ... ?

It's not clear if we should conditionally perform the queries but always invoke the theme function to give sites a trivial way to embed the view output at the same spot, or if we should only invoke the theme function if we already performed the queries. Maybe we want two theme functions -- one if we're doing the queries (no views) and need to render the table, another if views is present and we're not doing the queries.

No matter what, I think patch #9 can't be committed as is, since it's sort of the worst of both worlds. ;) Marking CNW.

Ah, ok. Now I understand what you've meant.
The cleanest (and simplest) way would be one theme in signup_no_views.inc and one in signup_views.inc in my opinion.
Then the user (themer) can decide to display the list no matter if views is enabled or not. Default for views enabled is not.
Patch attached...

#13 still has the problem that in the overwhelmingly common case (site will use the view for the attendee list) we're doing those two DB queries for nothing, which is bad for performance. That's the big point I'm trying to make -- I want to turn off those queries when they're not needed, but I'd rather not "turn them off" by having them directly in the theme function. Does that make sense?

Hey, you're still awake! :-)
I know, the DB queries would be unnecessary in this case. But what if a user has views enabled and wants to display the information additionally at the bottom of the node? How do we know when to query the data?
A simple if (module_exists('views')) would not work because in this special case the data must be queried although. If there were a "reverse flag" saying "theme_signup_user_list() ist overwritten" it could be done but without it...

The only option I see would be putting the queries into the theme function. But this is not really the way we wanted it to work, isn't it?

Or a global (advanced) setting for the admin to specify if they want to use a view for this or not... That's what merlinofchaos suggested to me in IRC when I asked him for advice on this problem about a week ago.

Well, I added the option to control where to display the list to the advanced settings.
Now the admin can decide whether to show it on a tab, at the bottom of the node or both. The options are only available if views is enabled. If views isn't enabled the list is always shown at the bottom of the node (depending on theme_signup_user_list().

Not tested yet, but I like the current solution. I'll run through it later today.

Here's a screenshot of the new setting: http://i37.tinypic.com/xnujaf.jpg

I can't seem to make the options work. It looks like the actual value set is never used, and that it's only being tested a true / false variable? There is:

if (user_access('view all signups') && $display_list) {

But $display_list is never checked to see if it is 1 or 2. The view is always displayed on the tab, and never at the bottom of a node. Is there something I'm missing?

Also, in the help text, I think Views is a name and should be capitalized: "If Views is enabled a view...".

--Andrew

There is a new option on [admin/settings/signup] to set this.
See screenshot above.

 Stefan

This needs some help. I'm working on it right now. Sadly, the really slick thing I was hoping to be able to do seems impossible in D5 views, so that might have to wait for the D6 port. I'll explain more once I'm done chatting w/ Earl. Just wanted to "claim" this issue so no one else spends time either reviewing/testing #17 or working on a new patch. Stay tuned...

Huzzah! Mammoth patch for what should be an easy feature... But, I was on a learning experience binge and got carried away trying to bling the UI with jQuery... ;)

• The same default view from previous patches.
• The main new setting controls what kind of signup user list you want under the signup form. There are 3 options:
  1. The hard-coded signup listing (controlled by theme_signup_user_list())
  2. Embed a view there
  3. Don't display a user list at all

  Obviously, you only get option #2 if you have views enabled.

• If you chose to embed a view, more settings are revealed that let you select which view you want to embed, and what view type (page vs. block) to use. By default, you get the default 'signup_user_list' view here, but in theory you could define your own whole new view for this instead of just customizing the default view.
• Added a signup.settings.js file and the appropriate div/css support in signup_settings_page() to show/hide settings based on the other settings. See the comments in signup.settings.js for full details, or just try it yourself. ;)
• Updated the INSTALL.txt and UPGRADE.txt files about these changes.

Phew! I've tested this pretty heavily now in all the cases I could find, but more eyes and testing would be most appreciated.

Thanks,
-Derek

Awesome!
It looks really (really, really!) great.

I think this can be committed (and doesn't block #293005: Create a signup 5.x-2.5 release anymore).

 Stefan

Committed to HEAD. Yay. ;)

This is quite nice, and works fine for me. I'm going to have to steal your jquery code for the conditional options - that's something that my users would really like for many of their forms.

I think the Views Page / Block option is a little confusing, but I'll file a new issue with a help text patch.

--Andrew