not being able to adminster signup statuses
mdowsett - March 18, 2009 - 19:35
| Project: | Signup Status |
| Version: | 6.x-1.x-dev |
| Component: | User interface |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
Description
I've used the D5 version of this for a long time....but I can't get the D6 working (at least as the D5 version worked).
I've set up multiple status codes for the event but in the event setup, there is no option to set the # of allowed signups for each status code....there should be right?
And from the admin signups for an event, there are no options in the dropdown to change a signed-up user from one status code to another...it's been a long time since I've installed this module (in D5) but this is a fresh D6 install and I can't seem to find any settings that would help.
#1
Views Bulk Operations is now used for handling advanced status changes.
As I understand it, it works like this, once you have Views Bulk Operations (http://drupal.org/project/views_bulk_operations), Signup, and Signup Status modules installed:
1. Go to /admin/settings/signup_status and add your custom status codes.
2. Go to /admin/settings/signup and in the "Advanced settings," for How to display the administrative list of signed-up users choose "embed a view and in the "View to embed for the signup administrative list" drop down, select "signup_status_user_vbo_admin ..." You've just enabled Signup Status' default Views Bulk Operations-enabled view for the admin list of signed up users.
3. Visit /node/N/signups/admin (where N is the node ID of a signup-enabled node). Now, where the "Signup Details" operations area used to be, you'll have a "Bulk Operations" area that looks similar. This is the Views Bulk Operations view, and it allows you to perform operations (from the drop down) on selected contents of this view.
4. To alter the signup status on a signup record, click the checkbox next to that signup on this page and choose the "Alter signup status" operation. Click execute.
5. Here's where my understanding falls apart: If in step #1 you didn't check "show on signup form," your custom status will not appear as an option on the page that loads. I don't understand the reasoning behind this. The "show on signup form" setting states that it controls whether or not users signing up can set their own status. Why does this setting influence the availability of the status here?
mlsamuelson
#2
The function involved is at line 106 of signup_status.module.
/*** Create the configuration form to select which signup status to use.
*/
function signup_status_alter_action_form($context) {
$options = array();
foreach (signup_status_codes() as $cid => $code) {
if ($code['show_on_form']) {
$options[$cid] = $code['name'];
}
}
$form['signup_status'] = array(
'#type' => 'select',
'#title' => t('Signup status'),
'#options' => $options,
);
return $form;
}
If you change line 112 from
if ($code['show_on_form']) {to
if (!$code['show_on_form']) {the statuses will display fine and the status change occurs as expected.
#3
Patch to fix this issue. Not sure why the aforementioned check was in there, so removing it.
#4
@mlsamuelson
Agreed. This doesn't really make sense here because this isn't the signup form - this is a bulk operations change.
I have implemented the code and can verify that it works.
Note: The code in the patch (#3) is different from that in in #2. In number two the IF statement is altered to be:
<?phpif (!$code['show_on_form']) {
$options[$cid] = $code['name'];
}
?>
While in the patch, the IF structure is removed so that the status code is added without condition:
<?php$options[$cid] = $code['name'];
?>
Also, thanks for the documentation - I had no idea Views and VBO were required.
#5
Agreed. #3 is the right approach. The original check was basically just a thinko on my part when adding this. I was thinking that if the status is hidden, it shouldn't show up in the UI, but this is the admin-facing UI, so it needs to show up somewhere. ;) Committed to HEAD. Thanks, folks!
#6
Automatically closed -- issue fixed for 2 weeks with no activity.