Disable cancel own signup when signups closed
borgo - March 6, 2009 - 17:27
| Project: | Signup |
| Version: | 6.x-2.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs review |
Description
Now, as far as I observed, users with Cancel own Signup permission can Cancel their signups anytime, even for nodes already set as Closed.
I would love to see the option to turn it off... When you for instance need to archive who signed up for what in the past.
BTW great module. Thanks!

#1
Can't decide if this is duplicate with #279622: Add a setting to prevent cancellation after a certain date or a separate request...
#2
When you organize an event and pay for a number of signed up users (food, room, etc.), then half of them cancels one hour before the event... even if the signups are closed - I find it very annoying, and believe others will agree. This loophole defies the whole purpose of signups - signup is a commitment. Even more annoying is when after the users attended the event and then remove themselves from the list - why should they be able to do that?
I think the original request will not work properly when the events are seat-limited. Signups will be closed when the limit is reached even before the signup close date. Then we want to still allow cancellations, so others may be able to signup before the close date into a newly opened seat. So I want to keep the signups limit logic intact, therefore I cannot rely on $node->signup_status. I found I can use a very helpful _signup_date_node_completed() function instead of current node signup open/close state.
So I did some coding around it. I believe that I don't need another date setting besides the signup close date, or an enable/disable setting. So if it is past close date, no one can cancel their signup, only a signup admin can. It turned out not too big a change in 3 critical places, but it works like a charm. Patch is attached. Please review for committing to 6.x-2.x-dev.
#3
You should use _signup_node_completed() rather than the specific _signup_date_node_completed()
I didn't test your patch, I'll do that later, as I am interested in this functionality.
By reading the patch I think you're only checking if the node could be auto-closed by x hours before, but I think you should check if the node is manually closed aswell. I'd say in most cases, signup and cancellation will be restricted in about the same way, so you could just check if signups are allowed, and assume if signups are open, cancellation is allowed (with proper permissions).
#4
#5
@Eirik_R
Thanks for your comments. I looked into _signup_node_completed(), and totally agree that it is more appropriate, since it deals with both date and event type nodes. I can roll another patch if needed.
In respect to your other comment, I agree that signup and cancellation will be restricted in about the same way. But my sense here is that you don't want to rely on if the node is just closed for signups, because there can be another logic in action. As i said in #2, "Signups will be closed when the [count] limit is reached even before the signup close date. Then we want to still allow cancellations, so others may be able to signup before the close date into a newly opened seat." I stand by that statement. That is the reason I did not use $node->signup_status that is readily available.
#6
Good thinking, I didn't think of the possibility of signups being closed when it is full. Reread #2, and apparently I didn't read it well enough.
The possibility I'm considering are nodes that are closed outside the x hours limit. The _signup_node_completed() don't check for other than this timer. I'm working on #290249: Make autoclose time per-node, not just site-wide, and there's http://drupal.org/project/signup_scheduler and there's manual control of open and close, and there's probably more. In all cases I would expect a manager to want cancellation to follow (close to) the open/close state (when not accounting for full seats). Do signup need a more fine-grained status, or can we get around this in some way?
BTW, I just tested cancelling in a full event, and it doesn't reopen the signups. Is this a separate issue, something special with my setup (I've hacked signup quite a bit now) or something likely to be fixed along with more? Anyway, it seems cancelling needs some attention, but now I have to get back to university stuff.
#7
@Eirik_R
>I just tested cancelling in a full event, and it doesn't reopen the signups. Is this a separate issue...
I think it is a separate issue. I remember from reviewing signup code - there are some traces of logic that suggested reopening a meeting.
I think closing cancellations is a must-have functionality, and I think it should be fixed quickly in signup.module with a best known approach. The following discussion is needed for figuring out finer-grain controls and more subtle cases, but it may take many months before there are good conclusions.
To seed this discussion I can propose:
1. introducing a "decider" function, one like _signup_node_completed(), e.g. _signup_node_can_cancel(), and
2. introducing a hook (e.g signup_can_cancel($node,$uid)) and a standard implementation in signup.module. Modules extending signup functionality will be able to override the hook to make their own logic.
Meanwhile, here's an updated patch with _signup_node_completed() instead of _signup_date_node_completed(). I also removed module_load_include(), since signup_init() seems to do that already. Please review - is there anything that prevents this patch from commit to -dev?