Needs work
Project:
Signup
Version:
6.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
6 Mar 2009 at 17:27 UTC
Updated:
23 Jan 2011 at 15:32 UTC
Jump to comment: Most recent file
Comments
Comment #1
dwwCan't decide if this is duplicate with #279622: Add a setting to prevent cancellation after a certain date or a separate request...
Comment #2
iva2k commentedWhen 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.
Comment #3
Eirik_R commentedYou 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).
Comment #4
Eirik_R commentedComment #5
iva2k commented@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.
Comment #6
Eirik_R commentedGood 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.
Comment #7
iva2k commented@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?
Comment #8
iva2k commentednag nag
Comment #9
dwwIn principle, I'm okay with some flexibility about this, but I think it'd have to be a setting or perhaps separate permissions. I don't want to require that signups are open for anyone to alter or cancel their own signup, but I can see how some sites want it that way. I'd rather not overcomplicate it, so I don't think we need per-node or per-node-type settings or anything. I'm thinking either a global setting would be okay, or maybe two additional permissions (e.g. "cancel own open signups" and "edit own open signups", although those names need help to be more self-documenting and clear).
Also, changing the title to reflect what this issue is trying to accomplish, since I just marked #806578: Allow users to edit signup only if signups are open... duplicate.
Comment #10
MasterChief commentedHi everybody,
i am interested by the option from dww to have "cancel own open signups" and "edit own open signups", a patch will be provided soon?
If not is iva2k patch work properly ?
Thanks for your answer.
Comment #11
MasterChief commentedSome news about this feature ?
Comment #12
Eirik_R commentedI'm using the patch on a low-traffic site and find it to do what i want there.
Much improvement in this area is possible, and I'm not using it on the site which originally brought this issue to my attention as it is a halfway fix. Test it and find how well it suits your needs...
Comment #13
MasterChief commentedThanks for your comment Eirik_R !
If you don't seem to have discover a bug with this patch, i will give it a try.
Comment #14
MasterChief commentedI just try it and the button cancel continue to appear when signups are closed, i try the latest patch of iva2k, someone have the same issue ?
I think it's a very important function for this module.
Comment #15
MasterChief commentedHi dww !
"Disable cancel + edit own signup when signups are closed" and your solution to add 2 additionals permissions it's a must have, do you plan to do it in the next weeks ?
If not, somebody think it will be able to provide a patch ?
Thanks for the answer because the first ask was March 6, 2009.
Comment #16
MasterChief commentedHi iva2k!
I am using your patch, but it's seems that the line
doesn't give the right data anymore.
I would like to block users to cancel their signups when signups are closed.
I appreciate any help :)
Comment #17
MasterChief commentedComment #18
MasterChief commentedComment #19
iva2k commentedSorry MasterChief, I cannot maintain the patch for you - I just have no time for it. I froze the version of signup.module on my sites to way back when the patch worked. I'm sitting and waiting for the big development around forms to be committed, then maybe I'll revisit this. Meanwhile, try to figure it out yourself - it is (was) not that difficult.
Comment #20
MasterChief commentedI solved my problem without the API just yesterday, thanks again for your patch, we will see how this module will progress :)