Provide option to set a date to automatically close registration

Sounds like a good idea. This featue would be welcome for me as well

How about also adding an option to set a date when registration can begin/open? We like to post our events for publicity sake but not take registrations till 2 weeks before the event date.

Absolutely. We will prioritize this issue. Doesn't make sense to allow folks to register for events in the past.

Subscribing for future reference.

@drewbe121212 please use the follow button in the future.

I have a really old version of git on the server that generated this patch, so that may be the reason why it felt it needed to pretty much remove the entire file and then replace it. This is my first time dealing with patching a drupal module, updates etc but this patch was generated against the HEAD branch (Alpha release??). That at least was my intention.

Add two new columns to the registration_entity table (registration_start, registration_end).

	    'registration_start' => array(
	      'description' => 'Date to allow registrations to start',
				'mysql_type' => 'datetime',
				'pgsql_type' => 'timestamp',
	      'not null' => FALSE
	    ),
	    'registration_end' => array(
	      'description' => 'Date to end registrations',
				'mysql_type' => 'datetime',
				'pgsql_type' => 'timestamp',
	      'not null' => FALSE
	    ),

This adds the two new settings to the registration settings form that allows the user to set the beginning and end date (if they so wish) of when registrants can register to an entity.

@dpi, if I completely messed this up I hope you can instill some guidance on me and I will try again.

I think it would make sense to avoid adding the datetime to {registration_entity}, instead some logic to expire based on a date.module datetime field attached to the entity. This allows the date to be recycled with existing modules, and you get all the fun formatters for date.

Your patch seems to be borked somehow :/

I need to upgrade git really bad on my server (1.5), will make another attempt at it. I am running a distribution of CentOS that is really far behind in it's git version unfortunately, and I would have to compile it manually to get it up and running.

As for the date time columns... I did toss around the idea of using date data from an already added column on the registration form. However, there are times I know where I need to set the registration start date and the registration end date at a time different than the actual event dates, for instance, if registration deadlines are a week before the actual event takes place. This could just as well be remedied by having the settings option changed from a date time to a 'close registration x days/weeks/months before y date.field'.

Or are you suggesting the ability to create any date fields through the form, then selecting those fields on the settings page saying "This date field is to be used for registration end dates". To me, it seemed like they should be separate, but I could be missing something that is standing out to you.

Thanks for the feedback.

For this functionality, no end date is required. What purpose does it serve?

If you want to have functionality such as closing dates X days before the event begins, then I would suggest the following if using my method:

Add two date fields to event entity

Field A (datetime): Date of Event
Field B (datetime): Registrations close on.

Set the special event closing functionality to when nowtime > Field B value.

Add a hook that detects creation of Field A data, and set Field B data programmatically based on an offset (of X days). This offset could be a global variable, hard coded, or even a field on the entity! (eg: `close x days before` select field with option values: 1, 2, 3.... days)

Even in the interim, instead of changing the schema, there is already an extra "settings" field in registration_entity that is a serialized field, so you could just add a new value to it's array that holds the closing date. It'd be a lot easier to custom code that functionality a lot quicker than the date field, even though the date field is preferable.

It'd at least give you a solution until a patch can be made for date fields.

I have created a small module that implements what I described in #7: http://drupal.org/sandbox/danph/1457366

@levelos and co,

Is there any interest in having this functionality in registration? As a submodule, or core registration.module?

Or should we start some contrib modules?

Hey @dpi, yes, we're interested in having this in core and actually have some work completed in a dev branch. Our initial preference was to not rely on the date field module for core functionality, E.g., event reminders, open, and close dates. Our working code has a single date property, and open, close, and reminders are relative values, much like what you discussed. We did run into an issue with the relative approach, though, in that cron needs to query the database directly based on the current day, so storing a relative value didn't work great across databases.

As for date field module, we could easily a code snippet to copy over a parent entities date field value in the registration date on entity_udpate or something.

We're a bit buried with other issues at the moment, and would welcome any patches to flush this out. Sorry for the silence and delay on our part.

@levelos Did you want to share your current code, or start fresh?

@dpi, I just pushed a branch called date-handling to d.o. We did that work a while ago, and I doubt the branch will even merge cleanly anymore with 7.x-1.x, but it's a good starting point. The code / approach needs some work, namely that dates used in cron handling need to be stored as actual dates to make performance reasonable. If you like, have at it and post a patch back. Thanks for your continued involvement!

Attached a patch. Similar code to what @levelos committed in the date-handling branch. Added a helper function "registration_is_open" that is called on the registration_register_page, and checks open/close dates to allow registrations.

Large patch due to my text editor auto replace tabs with 2 spaces, oops :(

I have it tested on my site, http://www.joepontani.com/node/4/register. I have the event date set at March 31, 2012 (2012-03-31), open date is -29, close date is -2 (so it should open registrations 2012-03-02 and close 2012-03-29). Tested it at -30 open (today) and it shows the form as it should.

Hey gang, wanted to flush this out a bit more with our thoughts on how date handling could work, not this is the only/best way :)

Update registration_entity to have the following optional datetime fields / props:

• Open Date
• Close Date
• Reminder Date

Ditch the relative approach, too confusing and not needed. Rather than having a canonical event date field at the registration_entity level, which the registration doesn't need or care about, the parent entity can use Date field to handle that. Yes, a bit more work for admins managing events, but we think the flexibility is worth it. As mentioned in #13, someone could always have a bit of custom code to update the registration entity settings when a parent entity is updated, E.g., set the close date based on the parent's date field.

Let us know what you think.

@jpontani, our paths crossed. Does #17 line up with you were cooking up?

Nope, went the relative route. You're still going to have to store the field names in the settings, as if you have 2 datetime fields on the parent entity (one for the open/close date, another for just the reminder date) you won't know which is for open/close and which is for reminders.

I'll see if I can't work on a patch for that method later tonight, I'll be busy up until around 9pm (EST) or so.

@ levelos,

What you are suggesting is pretty much exactly what I did in my screwy patch listed earlier. It had no dependency on fields, and was included as part of the registration entity table. To me, that seemed like the most logical way to do it.

Using fields, I could see this as a desire as well, but the relativity thing comes into play then. I simply liked having the ability to set a hard start date and end date irrelevant of the fields attached to a node. Neither fields were required. You *could* set a start date and you *could* set an end date if you wanted.

One thing I didn't include though, which dpi did, was to use cron to disable the registration to the entity. I liked this. My version simply checked against the logic and denied access to the form, rather than touching the status of the registration entity.

@jpontani, to clarify, we really don't want the core registration system to be dependent on any third party fields, including Date field. Can certainly reconsider, but that's our current thinking. Not sure why you suggested we'd need to store the field names as you mention in #19. Thanks!

Without storing the field name, you don't know which field to check on the parent entity in order to see if it's the open date, closing date, or the reminder date. Registration would not be dependent on another third party field type, I simply mean the built in date field (didn't mean to type datetime). Without knowing the parent field names, you have no way to check dates without just guessing.

Understood, but I'm not convinced that linking the registration settings to the parent entity should be part of the core feature set. Seems that it's going to unique to each use case and easily handled with a code snippet. But I could be wrong. Either way, those values could be stuffed into the serialized settings object.

On the date field concept, which I keep promoting:

My thinking is that a registration field will be attached to an `event` entity, which is highly likely to also have a date field attached to it.

Per the sandbox module (#11), the only configuration it needs is which date field to associate with. Although it only has close functionality, no open, or reminder date. Which would be very easy to add.

Even the date module itself is linking to Registration right now. Surely they see some kind of crossover here.

@jpontani in the future, please add patches without any code style changes. I understand Registration doesn't conform to Drupal standards right now, but they can be done in other issues. Try to keep your new code conformant. Patches like this may prevent merges from other issues, and make it hard to read what you actually changed.

Thanks though. Ill dig through tomorrow.

@dpi, actually there are many use cases for this module in which the parent entity will not have a date field against which we can key registrations opening/closing, etc.

The primary example would be registration for an event "series" that is made up of multiple events. In this case, the registration entity might be attached to a "series" node - which in turn uses entity reference to link to multiple "webinar" events. In such a case, you might want registration to open 5 days prior to the first webinar and close 2 days prior to the last webinar.

In ThinkShout's opinion, there are just too many permutations to force this logic in the core entity registrations module. If the storage of these dates are in the registration's settings, folks have the option to set them however they want in code snippets or other contrib modules.

Re: dependency on the Date module - I understand your point (as I lobbied @levelos hard for this one late last year...). However, I've also watched the Date module struggle for stable releases over the last 4 years. It's an incredible module, but it's also really complex and is a huge dependency. Again, if we're just stuffing dates into serialized config for registrations - you can leverage the Date module in helper modules (contributed or custom) to get all that goodness, while keeping entity registrations lightweight and bulletproof.

@dpi, just want to stress that we fully support great date module integration, just don't want it as a dependency for what ever's agreed as core functionality, in this case open|close|reminders.

Also, one minor clarification,

... if we're just stuffing dates into serialized config for registrations ...

The dates for open, close, and reminder will actually be stored in datetime schema fields to make querying against them easier and more efficient. With the flexibility of the serialized additional settings, contrib or custom could store the parent entities date field name and do whatever's needed with it, E.g., updating the registration's close date based on a parent entity's event date. We'll even likely need this in some of our initial projects.

@seanberto you sold me on moving it to a different module.

No problem, I think having the open/close in schema could work.

One small thing is reminders, and letting a different rules/third party handle this. As In my use case, I require multiple reminders with conditions, and I don't think `one` reminder date and template would be helpful.

@dpi, awesome. Hope that you are able to share a solution in a separate module. Where you also interested in helping put together a patch to get the open/close dates into the schema?

Re: reminders, yeah, I hear you about having a single reminder date/template not being helpful for all use cases - but it does provide a nice simple solution for folks who might not use Rules module. And for those that do use Rules for sending reminders, at least managing the template markup at the registration level might proof helpful.

Give this a shot.

• Schema change: add open/close fields.
• Cron to automatically open/close registrations.
• Change registration settings for entity - add scheduling: open/close form elements.

This looks great, thanks @dpi! One point for discussion. Your setting the status to 0 during cron depending on the open/close dates. My initial thought was that test would be part of the access control callback for determining if the registration form would be available OR testing when initially loading the registration form and showing a message if it wasn't open. The former seems better all around.

I'm open for exploring which approach is best. My thinking was that folks could get confused on what status meant and how it integrated with the open/close dates. E.g., a user could set a open date, have the status enabled during cron, than turn status off, and have it turned back on when cron runs. Thoughts?

E.g., a user could set a open date, have the status enabled during cron, than turn status off, and have it turned back on when cron runs.

Automatically setting the open/close field to NULL if the date has passed is what I have implemented. It gets around Registration re-en/dis/abling registrations automatically.

...My initial thought was that test would be part of the access control callback for...

I should have included the the code in #11 where registrations would automatically re/enable on view. See hook_entity_view in attached patch.

Changes since #29:

• Add helper: registration_check_status()
• Add hook: hook_registration_check_status() --- could be helpful?, especially for Date integration module I have in the works.
• Checks registration status on host entity view.
• Checks registration status on registration_form build.

^^

@dpi, I don't think the status should be tied to the open/close dates. That logic should be unified in a single place, the access callback for registration. Status can remain it's own switch which can be flipped manually at an admins discretion. So the test for whether registrations are enabled would include:

• Enabled / status
• Between open and close dates
• Hasn't reached capacity

Although that last case could still make the tab visible and display an event full message. Not sure on that one.

I have a need for this, but would need it to be able to integrate with Commerce Registration, and possibly other modules too. I wonder if it would be better / more flexible to have the cron task fire a Rules event, that other components can then listen to. I also wonder if the default implementation should be handled by rules. The changes that would need to be made would be

1) Create a new Rules action for "Close registration", which handles updating the database to mark the registration as closed.

2) Create a new Rules action for "Open registration", which handles updating the database to mark the registration as open.

3) Create a new Rules event "Registration opens" which fires in the cron hook using the same logic as you have now, instead of calling the database update code here, fire the "Open registration" action.

4) Create a new Rules event "Registration closes", which also fires in the cron hook, again using the same logic that you hace now, instead of calling the database update code here, fire the "Close registration" action.

This would allow Commerce Registration to also react on the 'Registration opens' and 'Registration closes' events in order to update the status of the linked commerce product to active/inactive.

And, by having the 'Open registration' and 'Close registration' code wrapped in a couple of Rules actions, we allow lots more possibilities for dynamically opening and closing event registration based on almost any set of conditions and rules that you could imagine and build with Rules!

@mrfelton please create a new issue for new rules. thanks.

@levelos

So we want a helper to determine if new registrations are accepted?

Don't you think it could become a usability problem if the enabled checkbox is checked, but current time falls out of open/close date range?

I understand how capacity and status checkbox should not be tied together, e.g: if capacity reached then set status to closed. As the capacity value is expected to in/de/crease in value on occasion.

I think this is debatable. Does anyone else have any preference?

@dpi, I guess it really depends on what we are looking for. The biggest change (at least visually) that happens from that status is the register tab disappears.

If the tab is still present, but we are outside of the open/close dates, I would want the ability to specify a custom message to the users. The same should be said for capacity. Right now I believe the message is just hard coded. I would like to point out that there are times that my organization links to a registration form (tab) outside of the node content itself, and the specific notification messages may be useful about the current status of the registration.

If just the tab disappears, the lovely 'Access Denied' page is displayed.

So, yes, I am for keeping these items separate as well.

Don't you think it could become a usability problem if the enabled checkbox is checked, but current time falls out of open/close date range?

Good point. I suggest the following:

• Access control should remain more or less as is, checking user permissions and the status setting.
• Lets had a helper that checks if registrations are available based on open and close dates and capacity
• If not available, then display a message rather than the registration form.
• This same check should be part of the validation for a registration submission in case things have changed since the form loaded

With this approach, nothing needs to happen during cron. As for configurable messages, lets leave that out for now and go with a standard "Registrations are not currently available for [parent entity label]" or something similar.

The reason the cron update is there, is sometimes I cannot wait for an entity to be viewed for its status to set to closed/open.

Queries to entities (EFQ, views etc) may display the status, and display an entity is open. But when you click it, it is set to closed.

If not available, then display a message rather than the registration form.

Markup or drupal_set_message?

This same check should be part of the validation for a registration submission in case things have changed since the form loaded

This shouldnt be required if the check is done in the initial form definition, as $form will be rebuilt on submit.

The reason the cron update is there, is sometimes I cannot wait for an entity to be viewed for its status to set to closed/open. Queries to entities (EFQ, views etc) may display the status, and display an entity is open. But when you click it, it is set to closed.

True, but if we agree that status is not tied to open/close dates, I'm not sure how this applies.

Markup or drupal_set_message?

Markup please, someday configurable / themeable.

Re: Validation, true, but if we ever separate the register page from the register form, we'll need it. Seems safer.

True, but if we agree that status is not tied to open/close dates, I'm not sure how this applies.

I don't exactly agree with this.

In any case, see attached patch:

• Removed cron and live change status based on open/close values.
• Better hook for check_status
• Modified forms and menu callbacks to use check_status.
• Inline message displayed in forms on closed entities.
• If the status is overridden by date, or module hook, then display a message in registration settings page reminding the user.

Hmm, some slot code made is way in there (and with a bug)

Revised.

For anyone who is following Date integration, you can find the project here: http://drupal.org/project/registration_date

A neat example of how to use the hook introduced above is included.

Note: current -dev requires the hook introduced in patches above.

Here is the patch in #41 cleaned so that it applies cleanly through drush make

Any feedback mrfelton?

@dpi - After installing the registration_date module to test, I'm a little confused as to it's purpose. With the above patch applied, we get scheduling options directly on the Registration entity. If we then add date fields to it, then it seems like we have duplication of functionality. You can see what I mean in this screenshot. Now we have the date fileds and the scheduling fields - thats 4 fields, 2 for an open date, and another 2 for the close date.

As it seems like the scheduling functionality is being included in Registration itself, is there any need for the registration_date module?

Formatters, views integration, better widgets, better integration with other modules, existing data are date fields. Recycle!

Its duplicating functionality, buts it mostly about the data.

Also, registration_date gives you the option of using multiple fields (2..3..4 etc) for opening/closing entities.

Even if the user does not have permission to edit registration settings, he can change the field value and modify the open/close as a result.

As an administrator, you're probably going to do one or the other, and I'll probably provide an option to disable Registrations open/close date in registration_date.

@dpi - ok, that makes sense. But in that case maybe it would make sense to hide and disable Registration's own scheduling fields if Registration Date is installed. It's really confusing for user to have the duplication of the scheduling fields like this, and it really not clear which field, or wether both, will be used to control the scheduling. However, that's probably a discussion that would be better had on your module's issue queue.

After applying the patch from #45, I get the following errors when editing a registration entity:

Notice: Undefined index: open in registration_check_status() (line 603 of profiles/concern/modules/contrib/registration/registration.module).
registration_check_status('commerce_product', '1')
registration_registrations_settings_form(Array, Array, 'commerce_product', Object)
commerce_registration_form_alter(Array, Array, 'commerce_product_ui_product_form')
drupal_alter(Array, Array, Array, 'commerce_product_ui_product_form')
drupal_prepare_form('commerce_product_ui_product_form', Array, Array)
drupal_build_form('commerce_product_ui_product_form', Array)
drupal_get_form('commerce_product_ui_product_form', Object)
commerce_product_ui_product_form_wrapper(Object)
call_user_func_array('commerce_product_ui_product_form_wrapper', Array)
menu_execute_active_handler()
Notice: Undefined index: close in registration_check_status() (line 604 of profiles/concern/modules/contrib/registration/registration.module).
registration_check_status('commerce_product', '1')
registration_registrations_settings_form(Array, Array, 'commerce_product', Object)
commerce_registration_form_alter(Array, Array, 'commerce_product_ui_product_form')
drupal_alter(Array, Array, Array, 'commerce_product_ui_product_form')
drupal_prepare_form('commerce_product_ui_product_form', Array, Array)
drupal_build_form('commerce_product_ui_product_form', Array)
drupal_get_form('commerce_product_ui_product_form', Object)
commerce_product_ui_product_form_wrapper(Object)
call_user_func_array('commerce_product_ui_product_form_wrapper', Array)
menu_execute_active_handler()

Looks like it's missing an up update hook in the install file.

Until levelos gives us the heads up, there are no updates in alpha. I'll add one if requested. Until then add the fields manually.

@mrfelton On another note, I added disabling registration.module date functionality in registration_date.module

I added the update hook to create the 2 new fields. That gets rid of the errors I noted in #48.

Hey gang - Just committed 71e3dbefb99884f214adee42629743f443b3eae7.

@dpi, thanks for all your help. I did find a handful of issues with the patch and took a slightly different approach. I hope it still serves your needs, if not, lets try and tweak things so it does.

@mrfelton, d.o. policy is generally not to include update paths for alpha code and I've been following that as we could still have significant schema changes. That said, happy to take your patch and I added the hook_update_N().

Thanks everyone. Will take a look and test out the latest release soon.

Excellent stuff, just a few things:

• registration_get_properties still required by RegistrationMetadataController class. As a result, errors are displayed whenever Views try to display registrations.
• Need registration_status check for field formatter. Added registration status check in registration_register_page_access, which formatter and menu tab use for access.
• Incorrect usage of drupal_alter.
• multiple_registrations form element access check may be incorrect.

On coding style: Conditionals shouldn't be split onto multiple lines. ( http://drupal.org/coding-standards )
You shouldn't keep *everything* under 80 char length.

Also, it would be great to get some feedback on #1472250: View and edit own registration permissions.

Thanks @dpi. Feedback:

• I don't want registration_register_page_access() to use registration_status() intentionally. When a registration is full or outside of the open date range, we still want to access the register page and display a message to users. Site builders can adjust the message, etc. per use case.
• I do want that check in registration_register_page()
• Good call on the field formatter, I added a check to registration_status() there
• Restored registration_get_properties()
• Updated drupal_alter() implementation

All those goodies are pushed.

Currently it's pretty difficult to enter dates for open and close of registration.

There should be a way to use relative dates for these open/close dates.

Typically registrations are being used for events, which all have dates. Can we get a way to automatically set the close of registration to 1 day before event date (or other relative number?) without having to manually check the date of the event and input it with the long input format (YYYY-MM-DD)?

Leaving the "open" date blank currently opens the registration immediately , but it would be great to just indicate something like "1 week before event" or "now," or at least use a date picker.

This functionality would also be great for the Send Reminder field, so you can just say send remind 1 or 2 days before the event. The signup module had this functionality going already too.

Thanks

If it interests you, I'll be adding offsets to Registration Date in the near future.

Thanks! Didn't even know there was a Registration Date module... how come there is no link on the entity registrations page?

Are there any other useful 7x plugins like this?

For now I'm taking the Registration Date module route, because it offers a date picker and the reuse-able values, although looking forward to this being integrated into the entity registrations module hopefully.

It would also be bomb to have a similar module or functionality (relative dates, datepicker) for the send reminder since you'd want to set it to send the reminder a day before the event date.

There's a bit of cross posting in this thread. But I'll chime in to say, @digitopo, that we're not likely to include the date picker in the core module - as that would create a dependency on the Date module. As great as the Date module is, it's a lot of code, often presents security issues, etc. DPI's add-on module is a great way for folks to get this functionality via a small helper module, without introducing a significant dependency for everyone who needs registrations.