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!

Comments

dww’s picture

Can't decide if this is duplicate with #279622: Add a setting to prevent cancellation after a certain date or a separate request...

iva2k’s picture

Version: 6.x-1.0-rc3 » 6.x-2.x-dev
Status: Active » Needs review
StatusFileSize
new3.03 KB

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.

Eirik_R’s picture

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).

Eirik_R’s picture

Status: Needs review » Needs work
iva2k’s picture

@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.

Eirik_R’s picture

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.

iva2k’s picture

Status: Needs work » Needs review
StatusFileSize
new2.84 KB

@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?

iva2k’s picture

nag nag

dww’s picture

Title: Disable cancel own signup when signups closed » Disable cancel + edit own signup when signups are closed
Status: Needs review » Needs work

In 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.

MasterChief’s picture

Hi 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.

MasterChief’s picture

Some news about this feature ?

Eirik_R’s picture

I'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...

MasterChief’s picture

Thanks for your comment Eirik_R !

If you don't seem to have discover a bug with this patch, i will give it a try.

MasterChief’s picture

I 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.

MasterChief’s picture

Hi 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.

MasterChief’s picture

Hi iva2k!

I am using your patch, but it's seems that the line

$open = !_signup_node_completed($node);

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 :)

MasterChief’s picture

Version: 6.x-2.x-dev » 6.x-1.x-dev
MasterChief’s picture

iva2k’s picture

Sorry 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.

MasterChief’s picture

I solved my problem without the API just yesterday, thanks again for your patch, we will see how this module will progress :)