Posted by jrbeeman on February 27, 2008 at 8:58pm
| Project: | Signup Status |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Issue Summary
From a reply by mdowsett in another thread:
the next trick would be to allow the event node admin to choose which of the available statuses to be shown on their event.
Different statuses could be appropriate for different event nodes...
thx again for listening!
Comments
#1
subscribing
#2
#3
As long as requests are being taken, in addition to allowing the admin to control which status are available with a node, also allow different status to be available to different permissions. For example, an anonymous users only gets ;Registered' and 'Wait List', while an authenticated user also gets 'Priority'. This would be controlled on the signup_status admin page.
This is something that is important to me and I am willing to work on it. Contact me if interested.
#4
Miglius committed some initial code for this to HEAD, especially now that #51226: allow users to edit their own signup is done. It's basically working, although the "show this code" setting is currently global, per-code, not something that can be configured per-node. There's also no support for permission-based ACLs on which code(s) you can select.
Sadly, I ended up needing to use a completely different form for new signup vs. edit signup, so there are different form ids at work here. But, that's no reason to duplicate all the code for the status selector form element. The first step towards any more fancy functionality is to make sure we only have to add any new features to a single place, instead of duplicating each change.
This patch depends on http://drupal.org/files/issues/330943_11_signup_status_form_alter.patch from #330943-11: Drupal 6.x port of signup_status.
#5
Reading this (and the other thread) more closely, I see that signup_status already had the code for globally selecting which status values should appear on the signup form, even in D5. This issue is specifically about further refining the choices per node. So, my comments above were a bit off topic. ;) But, I committed my patch from #4 to HEAD as a stepping stone for this and other similar issues.
@realEuph: Let's discuss per-status permissions over at #363797: allow different status to be available to different permissions and keep the separate features separate. ;)
Thanks,
-Derek
#6
Seems like the only way to implement this feature would be to add a new table {signup_status_node} which would hold per-node status settings. It'd need at least something like:
<?php'signup_status_node' => array(
'description' => t('Per-node signup_status settings.'),
'fields' => array(
'nid' => array(
'description' => t('Primary key: node ID'),
'type' => 'int',
'unsigned' => TRUE,
'not null' => TRUE,
'default' => 0,
),
'signup_form_codes' => array(
'description' => t('Serialized array of signup status codes to display on the signup form for this node.'),
'type' => 'text',
'not null' => FALSE,
),
),
'primary key' => array('nid'),
),
?>
Then, _signup_status_status_form_element() would also need a $nid argument. It'd query this table, and if there's a record, restrict choices based on the array of codes stored for that node.
Of course, we'd also need a UI (presumably by altering the node form) to select which codes should live with each node. It'd be nice to have that UI such that there's a clear separation between "just use the site-wide defaults" and "I need to customize the list for this node", and only store a record in {signup_status_node} if we're overriding. The way signup itself handles this for email templates and such really sucks, so it'd be good not to make the same mistakes here. ;)
#7
subscribe
#8
Any updates on this?
The site-admin can not provide every status needed by the event creator/manager, so does the ability to create new status by event creator/manager sound reasonable here?
To accomplish this, do we need to create a per node code table, such as: signup_status_node_codes, or simply inset the newly added status to signup_status_codes ?
Seems to me that, allow event creator/manger to insert new status in sigup_status_codes table is easier, and straight forward. However, problem will arise if multiple events share a status, but require different settings upon it: such as, having different requirement on "Modify signup count".
Any thoughts on how to do this?
Thanks.