Seems to me that given all the other stuff you can control per-node, it doesn't make much sense that the autoclose time is a single site-wide value. I noticed this when working on #213239: hide event specific features when module not available, and I don't see any existing issues about it. Wanted to jot it down so I don't forget, and to gauge interest.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

shanefjordan’s picture

I think it would definitely be worth while to have this setting as a global setting that can be overridden at the node level.

- Shane

dww’s picture

Wow, in fact, there's already a "close_in_advance_time" column in the {signup} table which has been around forever but was never used. Weird...

jrbeeman’s picture

This functionality is available via the Signup Scheduler module. It sounds like it might be worth bringing some of its features over into the core Signup module.

Eirik_R’s picture

Version: 5.x-2.x-dev » 6.x-2.x-dev

I have been considering now for a few days to chew into signup and try to implement this, but I'm not really comfortable doing it. So I'm hoping someone else could have a go if I bring it up and add my ideas.

First of all, I've looked at the signup scheduler, and to me it looks like jrbeeman don't have the time to finish/maintain the module.
By my idea of a signup module, the feature of auto-open and auto-close at set times really should be a core feature with per-node ability. The current site-wide hours before I think is a good thing to provide a default value, but I can't see it suffice for a proper module.

So what do I think signup module needs to have this:
change the current (unused) closed_in_advance_time column of {signup} should be changed to close_at, which would be the actual closing time for signups on the relevant node. Likewise, there should be a open_at, with the time to start signups.

Now a signup_autoclose function could simply check for two possibilities:
1. not full && current_time > open_at ==> open signups
2. current_time > close_at ==> close signups

Should make autoclose rather simple(, I believe).

Then there is a need to provide each node with the possibility to set a start and/or endtime (either absolute or relative to the event time comparable to current system) and store those times as absolute times.

Atleast these are my thoughts to how this should be implemented. I think this should be done for D6, but I'm guessing it will have to wait for signup2. My opinion that I'm guessing is less popular, is I would want to set Date API as a requirement if I were implementing this.

BassPlaya’s picture

subscribing...

Eirik_R’s picture

Assigned: Unassigned » Eirik_R

Just wanted to give a little notice that I'm working to get this functionality in.

Current status is:
-Site-wide default relative time for open and close
-Per node interface to define an open/close time

Looks great so far? Here are the problems:
-So far only supporting date, not event
-Not started to implement the opening and closing of signups

I am very certain the patch I will eventually post will need some love before it becomes useful.

Goodnight

Eirik_R’s picture

FileSize
20.48 KB

So, here's the state of my attempt to get a per node time for opening/closing signups.

For me this patch works. It is rough, and definitely not production site ready.

Issues:
- I don't think event.module sites will be to happy about this patch, as it builds on date api.
- Autoopen function is potentially problematic, it could need a disable function if signups are manually closed.
- Code duplication, and less good (bad) function names.
- No change to hook_schema or updates, so must manually add columns {open_at} and {close_at} of type DATETIME to {signup} table.
- Probably more, I'll edit as I think of them.

Ignore this patch, and check the next.

Eirik_R’s picture

Assigned: Eirik_R » Unassigned
Status: Active » Needs review
FileSize
20.79 KB

Returned the hook invoke lines to get the watchdog messages right.

Add a few issues above.

dww’s picture

Status: Needs review » Needs work

Thanks for taking a stab at this! However, this is all wrong... ;)

A) We want to continue to support multiple date backends here. As much as I dislike supporting the event.module, many people still use it with signup, and I can't just throw all of them out the window. There's a lot of effort that went into providing support for multiple scheduler backends, and this patch undoes most of that. I don't have time right now to design a proper solution for this, but what you've got here won't work.

B) Your patch still includes some commented out debugging lines.

C) There are a lot of whitespace and code-style problems (improper indentation, using tabs not spaces, adding stray newlines, etc).

D) If your patch makes some functions obsolete, you should just remove the functions, not comment them out.

It's not really worth my time to closely review this until there's a viable solution for (A) in place. Please let me know if you have questions and need help coming up with a plan. Otherwise, I really look forward to reviewing the next patch here...

Thanks!!!
-Derek

p.s. There's no need to edit your previous comments when you post a new patch. If you post a new patch, it's self-evident that that's what should be reviewed, not the previous one. ;)

Eirik_R’s picture

FileSize
19.89 KB

Just to report progress, here's a patch with today's improvements. Your comments B-D should be mostly fixed by this. This one should now work under perfect conditions.

About A. It's not my intention to remove support for multiple backends. I think current problems with multiple backends and this solution is that other backends are not yet considered. I'm putting together more of a proof of concept, than writing a stable patch ready for production. My aim with this series of patches is mostly a discussion on concept.

However this patch should have a few improvements to support PHP4 and have flexibility for more backends compared to yesterday's. I've also started to try to work around requiring Date API by providing a low-functionality fallback.

Warning: I think this patch might break the includes/scheduler.inc due to an error by cvs diff. I haven't tried applying it myself.

Derek: I understand you are busy these days. When you find you have the time, please drop your comment about the way of implementing autoopen/close.

Eirik_R’s picture

A little progress is made. I was almost ready to move this into my production site, then some bug with timezone handling showed up.

Now with support for event.module aswell.

I will now try to find the tz-bug and then get this into my site. If anyone else is interested in having this functionality in signup, make some noise and I'll do any further work required.

PS: The bug seems not to be caused by this patch, and when I can confirm that, I will put the patch in production.

Eirik_R’s picture

FileSize
20.52 KB

And the new patch...

ambereyes’s picture

subscribe

scrofula’s picture

subscribe