Jump to:
| Project: | Signup |
| Version: | 6.x-1.x-dev |
| Component: | User interface |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Issue Summary
The final piece of the signup limits design spec I wrote (and posted over at #359412-3: Move code for signup limits per status per node into a submodule) which needs further work is to somehow revamp the admin/content/signup administration overview page. However, this page is plagued with problems:
A) It's all hard-coded and inflexible.
B) It's very difficult to alter from other modules, since there's no way to alter the query used to generate it.
C) It currently displays unpublished nodes: #547758: exclude unpublished nodes from admin signup list
D) The operation links are kind of stale.
...
Ideally, I'd just replace it with a view. ;) See #582986: Make views a required dependency and ditch non-views code
I guess I could even rip out that particular page and provide a default view for it, without making views a dependency. That page isn't essential to the operation of the module, so it could be something that's value-added once you enable views. There'd also be a VBO-enabled version of the view that let you do stuff like open/close signups in bulk, modify the signup limit, etc.
There's a start of an exported view for this page over at #582986-2: Make views a required dependency and ditch non-views code which we could build on for this.
The hardest thing to replicate would be the magic for displaying the signup start time for all nodes, regardless of which kind of date field or event.module date info is being used for the signup start time of each node. We can't actually sort by that because it spans multiple DB tables and columns. I'll have to check with merlinofchaos about if there's any reasonable way to replicate the existing automagic behavior...
Comments
#1
Hi dww, I'd like to help here. I'd like to be able to replace the default list with a view. I think maybe the best approach, given the current state of event and date modules, would be to leave the hard coded list as the starting default and if they have views installed and using date, then allow the user to specify a replacement view. At this point, event has not yet released a non-dev version of the module and date has nearly 10x the number of sites installed. If someone still using event wants to step up and write their part, that would be great. VBO would be very handy to have on this page as well. Additionally, I want to use signup_pay with signup and would like to be able to show on this admin page whether an event is enabled for payment and the fee, etc.
I will put it on my list to take a closer look and try to see if I can pull together a patch. Let me know if you are still interested in moving this forward.
#2
Sure, I'm still interested in seeing this move forward. Thanks for volunteering!
I think making views a dependency and dropping event support before 6.x-1.0 would be too big of a change, but I'd be happy to do both of those things in 6.x-2.* and 7.x-1.*... ;) So, for the 6.x-1.* series, adding another config knob for what to do with this page would be fine with me -- where it either provides the existing hard-coded page or lets you select a view to use on this page, instead (similar to the other settings in signup that let you use the view of your choice for various things).
#3
OK, sounds good. It's on my list and I have a client that wants it done so hopefully I can submit a patch sooner than later. The list is long and this one is not on the top of the client's list, so it will probably be a few weeks minimum before I have something to share. I will post a patch here when I have something.
Looking quickly, I am thinking we could duplicate or extend the code below pasted from includes/admin.settings.inc to pick a view to use. As well, we would need to provide some default views that people could start from and alter the includes/admin.signup-administration.inc to use something like what is used in the function signup_node_admin_page($node) display either the provided table or use a view.
Let me know if you have an any directional advice.
<?php
$views = views_get_all_views();
foreach ($views as $view) {
foreach (array_keys($view->display) as $display_id) {
if ($display_id != 'default' || 1) {
$key = $view->name .':'. $display_id;
$view_options[$key] = theme('signup_settings_view_label', $view, $display_id);
}
}
}
$form['adv_settings']['view_settings']['signup_user_list_view'] = array(
'#title' => t('View to embed for the signup user list'),
'#type' => 'select',
'#options' => $view_options,
'#default_value' => variable_get('signup_user_list_view', 'signup_user_list:default'),
'#description' => t("If the signup user list is being generated by embedding a view, this selects which view should be used. The view's name, description, and display(s) it defines are listed."),
);
$class = 'signup-admin-list-view-settings';
if (variable_get('signup_display_signup_admin_list', 'signup') != 'embed-view') {
$class .= ' js-hide';
}
$form['adv_settings']['admin_view_settings'] = array(
'#prefix' => '<div class="'. $class .'">',
'#suffix' => '</div>',
'#weight' => 6,
);
// $view_options is still initialized from above.
$form['adv_settings']['admin_view_settings']['signup_admin_list_view'] = array(
'#title' => t('View to embed for the signup administrative list'),
'#type' => 'select',
'#options' => $view_options,
'#default_value' => _signup_get_admin_list_view(),
'#description' => t("If the administer signups user list is being generated by embedding a view, this selects which view should be used. The view's name, description, and display(s) it defines are listed."),
);
}
?>