Registration status, handling status when it is no longer available

Good questions @dpi, and I'm open to suggestions.

How is this status exposed to users?

I suppose if could just be NA or something along those lines. I don't see this being a common situation.

How will other modules know it is OK to override this status with something else?

Not sure I understand your question. They could look in the API docs?

Should multiple status be allowed per Registration?

I don't think as part of core. E.g., if a payment is processed, usually safe to treat the registration as complete. Additional fields with a matrix of statuses could always be added.

Feel free to close if nothing else, or leave open if we need to keep exploring ...

Not sure if you want this in another issue or not.

Another possible scenario (I know this scenario exists in COD setups with uc/signup):
Which statuses are taken into account in the count of actual registrations for an event? If I create a custom status of "Waitlist", it will still currently count against the total number of registrations for an event, even though it shouldn't as it is a waitlisted registration.

If I create a custom status of "Waitlist", it will still currently count against the total number of registrations for an event, even though it shouldn't as it is a waitlisted registration.

Actually it won't. Only Registrations with a status of "complete" counts against the total. But I can see how this could be limiting and maybe we need a separate schema for statuses with a flag on whether they should count against the total. Suggestions welcome.

Actually it won't. Only Registrations with a status of "complete" counts against the total. But I can see how this could be limiting and maybe we need a separate schema for statuses with a flag on whether they should count against the total. Suggestions welcome.

Ah ok. Wasn't sure if it did that or not (haven't looked at the code recently).

I know COD is looking at possibly using this module for its next version, so the following two things are features they're needing if this is the module they go with:

1. Each status can have its own signup limit for an event
2. Each status can count against the total signup limit for an event

Possible solution:
For both, in hook_registration_states, have more info returned in the array. IE:

$states['waitlist'] = array(
  'title' => t('Waitlist'),
  'state_limit' => 0,
  'total_limit' => FALSE,
);

Where state_limit is the state's registrant limit (maybe only 10 allowed on the waitlist, for example), total_limit is a flag as to whether any registration in this state would count against the overall registration limit, and title is self-explanatory.

You would probably want to store these in a separate table. That way you can have a UI to override settings that are declared initially in a module.

Just a thought.

Thanks @jpontani, great ideas. One issue to resolve is that an event's capacity is currently stored at the registration parent entity level, and can be managed per event. That seems to go against having a global limit per state. A possible solution would be to allow users to map limits to each state in the registration settings and store that in the serialized settings field. registration_has_room() would have to be updated accordingly.

@dpi, I hear ya', but we need more than a binary flip for registrations and at least some of it is needed in core.

One issue to resolve is that an event's capacity is currently stored at the registration parent entity level, and can be managed per event. That seems to go against having a global limit per state. A possible solution would be to allow users to map limits to each state in the registration settings and store that in the serialized settings field. registration_has_room() would have to be updated accordingly.

True, hadn't really thought out the solution completely, just first thing that came to mind. In that case the hook_registration_states could pretty much remain the same, just as you said, store the state's settings in the registration settings.

Discussion here feels pretty good to me.

My sense is that modules can create new states, but that Registration should ultimately keep that information even if the module is disabled to avoid the problem that registration are in a state that is no longer visible. This argues away from hooks for declaring states and for having an API to create states that a module would use during hook_install/hook_update.

I agree with greggles' point in #8 that it would be ideal for Registration to store the various statuses natively so that we don't run into the situation where a status is deleted.

But I can see how this could be limiting and maybe we need a separate schema for statuses with a flag on whether they should count against the total. Suggestions welcome.
[snip]
A possible solution would be to allow users to map limits to each state in the registration settings and store that in the serialized settings field.

A separate schema seems preferable to me. For example, see the schema for Signup_status.

As an example of how this kind of configurability can be used, here's screenshot from the Drupal 6 version of Signup status:

Beyond the popular waiting list and "payment pending placeholder" use cases described above, this kind of configurability provides a solid base for more customized attendee requirements. For example, I worked on a site that had different signup statuses set aside for folks from specific companies. The motivation was to ensure a mix of attendees from companies other than the one that was hosting the event. We used a special attendee status for the host company and programatically enforced a limit for that signup type, and automatically assigned the type to folks from the company hosting the event.

@ezra-g #9 needs moar file upload.

Looks good gang, we're on it.

This one's all set and pushed. The basics:

• Add a new schema for registration states
• Registration states are a new entity type, not fieldable, with the following properties: (machine) name, label, description, default flag, active flag to indicate if it should count against capacity, be used in broadcasts, etc., flag for including in registration form, and weight.
• Completed, Pending, and Canceled default states are created on install and removed on uninstall.
• There are several new state API calls, including getting all active states.
• Existing API calls have been modified to account for the new active states.

Feedback welcome!

@levelos - Thanks for the work and for documenting the changes in narrative form in #13. it would be great if you could post patches or the link to the commit to be able to go back and forth to confirm how the change was implemented. The commit for this is http://drupalcode.org/project/registration.git/commit/f36156c

Sure @greggles, normally I would. The changes are actually spread across several commits. We also found a couple lingering issues which we'll be pushing any minute now.

@dpi, we could force at least one state to be active. Otherwise, I think it's reasonable behavior for events to appear full and not send any broadcast messages if there are no active states.

All, one change to consider is a set of registration states per registration bundle. Adds complexity, but potentially useful. Thoughts?

All, one change to consider is a set of registration states per registration bundle. Adds complexity, but potentially useful. Thoughts?

Quite useful, in my mind. You might want to have a VIP role for one event, but another event might not have VIP potential. Just an example.

Marking this "meta" ticket as fixed so we can continue discussions as needed in other tickets.