Entity based registration module for Drupal 7

That's great, thanks for sharing.

There's also http://drupal.org/project/cck_signup -- did you ever talk to them?

Signup isn't dead -- it's used in http://drupal.org/project/cod and there's already a (sort of) working D7 port. It's just not a high priority for me these days, and I have a lot of other projects I'm worrying about.

I think a 7.x-2.x branch of "signup" that was a complete re-write to be entity-based would produce more community confusion, not avoid it. I also imagine you're not interested in trying to support a data migration path from D6 and D7 signup.module sites, right?

Cheers,
-Derek

I didn't know if the D7 port of cck_signup kept them as nodes.

We *have* been discussing a 7.x-2.x branch of signup where we just make signups entities, but not nodes...

Hrm. Before we get much further, I'd love to get ezra-g's thoughts on this...

I'll ping him out of band and have him reply here.

Thanks,
-Derek

We're all a bit confused. ;) No worries. I now understand a bit better what your thing is doing (I looked around at the code from the initial commit). Looks like it's just the beginnings of the shell of a thing -- no real functionality yet. I briefly chatted with ezra-g about it and he's going to ponder more and reply here.

Anyway, stay tuned...

Thanks for reaching out for the possibility of collaboration and coordination.

Cheers,
-Derek

In addition to http://drupal.org/project/registration, there's also the Entity signup sandbox project by jpontani, who is also working on a Commerce Signup module that would replace the uc_signup module.

@levelos, have you reached out to jpontani at all to see if there is an opportunity to collaborate on the entity signup work?

It's true that the plan for Signup is to do a straight port (non-entity) of Signup so that we can provide a D7 version sooner. I also agree that in the long-term, using the Drupal 7 entity system makes sense because it reduces the amount of code we have to maintain.

However, I'm also not clear on the specific functional advantages that the entity system would provide for end-users. One of the most popular feature requests for Signup is the ability to add arbitrary, event-specific fields for users to fill out when signing up.

Since the fields would be per-event, rather than applying to the entire signup class/every signup-enabled event, I'm not clear on how the entity system would provide better UX, even if some feel the DX is better.

So, if the main benefit of using the entity system is "less code to maintain," I would think that "port the existing Signup.module to D7" would require significantly less development effort than starting from scratch using the entity system, and would have the benefit with being aligned with the needs of the thousands of sites already using Signup.

@levelos, can you elaborate on your motivation for writing an entity-based signup system at this time verus working to accelerate the D7 straight port?

jpontani made the point that Signup's current ability to be associated with nodes (and not arbitrary entities) presents some potential architecture challenges with trying to sell Signups with Drupal Commerce. This is critical functionality for the Conference Organizing Distribution, so if having an entity-based Signup module greatly improved the ability to sell signups via Commerce, I would be more inclined to shift focus to an entity-based initial port. However, I would think that we could address this specific concern by altering the schema of the {signup} table to allow it to reference entites, rather than nids.

@dww, it would be great to get your input on that, probably over at #1232900: Commerce Signup (D7) - Development approach rather than here.

I agree with dww that having 2 competing D7 branches would cause confusion, but in general I'd really like to avoid whole project duplication, so if we can't all align our development goals on the project, I think a good compromise would be to for the folks working on D7 entity registration/signup projects to do so with the goal of being merged into a 7.x-2.x branch of Signup after some initial review.

To start off, I'm more than willing to collaborate on an entity signup module. I have some code but I'll probably be scrapping a lot of it as I think I started off a bit wrong on my design of the signup entity (first time trying to write entity code).

My reasoning for bringing it up to begin with is due to the way we (my work) want our signup system to work. Because we have multiple "product types" that each require different fields to be filled out whenever that product is purchased, there was no way we could work around the limitation of only have a single signup "form" be displayed to all users and expect them to not get confused when there was extraneous fields they needed to fill out that didn't apply to their purchase.

After looking at how Drupal Commerce was designed, we also couldn't get Signup to work with it directly as signups are tacked onto a node and not an entity. You can attach signups to Product Displays, but not products. While initially I thought it might be ok, after digging deeper I realized this wouldn't work for our scenario either as we would have multiple products tacked onto a product display that also might have unique fields required.

Also, I have more info over at #1281962: Allow Signups to work with Entities that was my initial concept.

Thanks for the update, levelos, will take a closer look there.

Out of curiosity, why are you developing this on Github rather than Drupal.org?

Just an FYI that ThinkShout's got a dev release of Entity Registrations posted @ http://drupal.org/project/registration if that makes it easier for folks to grab.

Also, I'd like to quickly point out that this module actually ships with a sub-module for managing "registrants" as entities as well. The idea is that a registration is an entity which can have fields, as can one or more associated "registrant" entities. This is helpful if you want to sign up more than one registrant with a single registration. Here's a use case (in fact, one that we're developing against for a specific client):

* An outdoor education facility host multiple student tours of their facility.
* A teacher wants to sign up her class for a tour.
* That teacher creates a single registration - filling out multiple fields, such as school name, class, emergency contact, etc.
* Then, that teacher fills out "registrant" information specific to each student - for example, t-shirt size, meal preference, allergies, etc.

The registrant sub-module "works" in the dev release. It doesn't respect the registration "count" field just yet - and there's definitely some UI affordances that we need to finish up. But otherwise, these two modules pretty much work.

----

On a separate note, and just to reiterate, we know that it'd be better if registrations could be hooked to any entity type, not just nodes. That's the next refactor - which shouldn't require schema changes, but will require some more complicated code.

---

Awesome to be engaging with you all.

I've been modifying Entity Registrations to accomodate multiple Registration entities, as well as attaching them to entities and not just nodes. So far I've got bundles working and fieldable, as well as the administrative side of things. Going to start working on attaching them to entities. Primary focus will be getting it to work with Commerce to start, but will try to have it working with any entity as well.

https://github.com/jpontani/Registration-Modifications (check the 7.x-1.x branch, the master branch is outdated).

I haven't tried the modules of #13 and #14 yet (curse my laziness!) but is it possible with these modules to be more flexible in the states of the signup?

E.g., instead of just:
'signed up | not signed up'
Have to possibility to add more states (user defined?), such as:
'signed up, and going | signed up, not going | signed up, doesn't know yet | not signed up'

Also, since this is now entity stuff, it should now also be possible to attach multiple events to a single node? Or is that me brainfarting?

Adding "states" would be quite easy since we're using the entity system - just at a taxonomy field to the entity type.

Adding multiple events to a single node, if I understand the use case correctly, wouldn't require this module. You'd probably create a content type call "Event series" or something like that, and then use node reference to add "event" nodes to the "event series" node(s). If you wanted to handle signups for those events, you'd enable this module and turn on registrations for the "event" content type (as opposed to the "event series" content type).

Both, personally. I'd love to see a single code base that has these types of features as I can't imagine there aren't others out there with similar use-cases or needs as I have. For now I just forked for my own personal needs, but have been coding it as such that it's not hard-coded for my needs, but such that others can use. Obviously I'm starting with the features I need, but will be expanding it some later when I have time. I'll definitely be submitting patches for it as well, and co-maintainer is fine by me if it works for you.

I've actually already got bundles tied to entity bundles as well, as I have that need personally. So for example, I have the need to have multiple Commerce Products be enabled to register for, but each with their own specific fields to be displayed on the registration form. So I can't just have a single registration bundle for the Commerce Product entity, rather I need registration bundles for each specific Commerce Product bundle.

Just out of curiosity (please feel free to move this somewhere else if inappropriate): will there be (or is there already) the possibility to dynamically retrieve notification email addresses from other related content nodes? This far, I have not found a way to do this but the approach using entities could make it work.
I will explain the scenario:
I am trying to set up a list of events that students can subscribe to. Each student is assigned to a school (the school itself is a node-reference, with an email field containing the teachers emailaddress). Upon registration, an email should be sent to the teachers' email address, the event coordinator and the student itself.
With the current implementation of the module, sending mail to the student as well as the event coordinator isn't a problem, but retrieving a field from a referenced node doesn't work. Who has an idea on how to accomplish this?

kind regards

Note that signup currently doesn't play well with latest VBO as VBO has moved to an entity-based approach. I considered VBO essential to displaying and using signup personally.

We've been using the initial code that we wrote wtih entity registrations with VBO pretty well the last few months. It allows for some pretty slick mass registration management/email tools.

subscribe

This is awesome, but it probably would be more appropriate in the Registration module's issue queue...is it kosher to move it over?

@ohthehugemanatee In my view this thread is primarily about how Signup should collaborate with the other 2 entity registration modules, so let's leave it in this queue.