associate registration with arbitrary entity types

Thanks for your help and interest @rudiedirkx! That's a great idea, or we may just go the route of allowing arbitrary registration bundle types and associating them with any entity, nodes, users, terms, etc. I'll dive into your code when we move ahead on this front.

@rudiedirkx, On the lines of #1, I've made my own modifications to Registration as well at https://github.com/jpontani/Registration-Modifications

I know levelos has seen me post this already in our other discussion thread, just thought I'd share in case you wanted to use arbitrary bundles rather than node-specific bundles.

Sorry meant to clarify, I haven't finished it yet :( Just had those parts working. Still getting the registration form itself built, validated and submission working.

I mirrored my work from Github to d.o: http://drupal.org/sandbox/jpontani/1307874

I'll be adding in some more stuff later, I've been busy working on Commerce Registration (http://drupal.org/sandbox/jpontani/1300768) that integrates my changes of Registration with Drupal Commerce.

My commit messages are kinda crappy right now, so I apologize that it's hard to actually figure out what changes I'm making. I'll be working on cleaning up my future commit messages as well.

I'll also be working on making a patch for Entity Registration that adds the changes I've made in terms of multiple entities, arbitrary entity assignment to other entities, etc. I don't have the basic functionality working just yet of the registration form working with other entities besides Commerce, so I'll be submitting patch for that later as well.

just a little comment to @rudiedirkx,
I think the menu path should be admin/structure/types/manage/TYPE/registration/fields so it will display as tab in the "edit content type" page , similar to the comment fields and comment display tabs.

Looking at @jpontani's work, it's a step in the right direction although I'm also not sure of the use cases for having registration on comments, files, etc. I'm guessing the purpose here is to be able to put them on other entities like products or custom entities where the use case makes more sense.

As far as linking registration bundles to another entity, in addition to creating a registration bundle and attaching that to the node:event bundle, we also should have the ability to attach a registration bundle not just at an entity bundle level, but to a specific entity. As an example if we have an event content type, and we create multiple events on our site, we may want different registration bundles for different individual event nodes - not one bundle for the entire event node type.

Has anyone put any work or thought into this next step?

While I agree that registrations for comments/files/etc seems pointless, I literally just looked at every single entity from entity_get_info(). I didn't want to hardcode any exclusions to that rule as someone might have a scenario (who knows?) where they want to allow for registrations on a file, comment, etc.

Coding to allow any registration bundle on a per "node" (loose use of the word node here, just using it as a reference to any specific entity item) seems a bit excessive in terms of coding. While I see the use and appeal, it's not something I can dedicate a whole lot of time to making a patch for currently, as I have some deadlines approaching for my projects that I have to worry about first.

I think what I'll do is have my Registration Entities patch as 7.x-1.0 and the per "node" bundles as a 7.x-2.0 branch.

Attached is a patched based on jpontani's sandbox work. There's a fair amount of cleanup and checking still to do but it's a first step.

I've got my current project nearly completed so I'll be spending more time working on making a patch that is a bit more inclusive than just adding the ability for stuff I needed without a real UI to manage it.

@jerdavis, I took what you started on (the registration_attach table) and am going from there to make it a bit more extensible in that you can specify either an entire entity type/bundle combo to use a registration bundle, or just specify that a particular entity uses a different registration bundle. This will get away from the variable system to attach registration bundles to entity bundles.

Hey there

i just tried out this module with the patch, and i'm getting error regarding to a missing index

Notice: Undefined index: #node in registration_entity_view_alter() (regel 211 van /var/www/www.vlaamswelzijnsverbond.be/sites/all/modules/contrib/registration/regi...).

i know this module is still under heavy development, i'm giving some feedback ;)

Renaming and reclassifying.

We're considering leveraging entity registrations for a project that involves commerce products + events + signups. We'd rather not have to create a custom fork to support putting signups on products. To that end we're willing to help with patches and testing.

I took the liberty of downloading jpontani's version and creating a patch. It seems pretty big.

@jpontani: Would you be willing to give a quick comment on where you are with this?

I guess my main question for the maintainers is whether it makes sense to use jpontani's version or try to tackle this in a smaller chunk/patch (if that's possible).

Thanks in advance!

@seanbfuller, yes, this patch is way too big and I have no idea where jpontani left off with it. It also addresses much more than just this issue. Any patch would have to be limited to just a single issue, in this case associating registrations with entities other than nodes. Thanks for trying to move this forward. Not sure where this will issue will go, but, regardless, we're going to address this fairly soon.

My version (which is what I assume you created that massive patch based on) tackles many issues that I needed in a registration system (registrations as entities, registration bundles associated with arbitrary entities, default settings, etc etc etc). There's quite a bit I've added since initially modifying this module to have custom bundles. A lot of this stemmed from my need to sell registrations with Drupal Commerce.

An overview of what I've done on my "Modified Registrations" sandbox:
- custom registration bundles that can be attached to any entity type, or specific entity
- default settings on a per type or per entity basis (goes with the above item)
- views integration
- started integration with Commerce Email and Mime Mail for sending HTML mail
- started to build custom registration statuses and the ability to attach custom statuses to specific registration bundles or specific entities (along the lines of the first two items)

What my version doesn't do as of yet is send any email upon registration success, or allow you to register for anything (yet), but the foundation is built to be able to have completely custom registrations. I had to get a project up and running really fast (2 weeks) so I had to modify as little as I could to get it working right away. If you're wanting to have registrations for Drupal Commerce, see my Commerce Registrations module.

Could probably just use the massive patch as a 2.0 dev branch (or whatever version) if you wanted. I'm still in the process of getting it finalized to be able to work out of the box with basic registrations.

Thanks for the responses. I'll probably dig in a bit more to see where I might be able to help roll a patch as it makes sense.

Off topic: @jpontani, thanks for pointing out your commerce registration sandbox module (http://drupal.org/sandbox/jpontani/1300768 for others who might find it interesting). I hadn't found that yet. It looks like it tackles some of the things that were next on my list. It's throwing a few errors about missing registration_entity_* functions, which are probably in your version of this module.

Thanks again!

Yea it is based off all my changes, sorry I forgot to mention that.

I finally got a chance to dig into this and explore what moving towards abstracted entities instead of nodes would look like. In order to keep this as small of a step as possible, I only focused on changing any references to $nid to be more along the lines of $entity_type, $entity_id. To make this happen I altered a few columns in the database, but kept it down to two tables. Upgrade hooks will need to come later.

Things I did NOT take on this round:

• How registrations are enabled for different entities (the node type list was not touched.)
• How registration forms would be displayed on other entities (nodes have full view pages with local tasks, which cannot be said for all entities. For example commerce products are only viewed in the context of a node page.
• Managing registration settings on other entities.

There are still a few places where $nids are being used. Many of these are in places where the context is a node's local tasks or where node specific information is being displayed (such as a node title). I wanted to get feedback before proceeding. Most of the internal functions that do the heavy lifting have been abstracted and the module still works for nodes after a quick round of testing.

In exploring this, I looked at jpontani's earlier work from #9. One of the things he added in that version was having multiple registration bundles. To help keep things manageable, I didn't add that in here.

Next steps:

A quick review to make sure that I'm on right path would be great.

Beyond that, I want to explore how to best get other entities integrated for the tasks listed above. I see two paths: one is to abstract everything so that this would work for any entity. I'm nervous that this may cause issues considering how flexible entities are. The other option would be to split out support for different entities into sub modules. This would push registration towards being an api with some default implementations (for example there might be a registration_node module and a registration_commerce module).

Feedback is appreciated. Thanks!

Sean - Thanks for the patch. I should have have been more public about our roadmap, but we're currently working on similar functionality, and then some. When complete, you can create arbitrary registration types / bundles, associate registrations with any entity type, or even with a particular entity. We're about 80% of the way there, with the code currently at https://github.com/thinkshout/registration/tree/abstract.

Would it be more helpful to post the in-progress code here on the d.o. project page? I had avoided posting incomplete code, but am happy to.

Ah, sounds great levelos. I'm checking out that version. Would you be able to share a quick summary of what you guys feel is remaining for this next round?

Regarding moving over to d.o:
I'm not sure what the standards are regarding unstable code in contributed modules these days. I understand why you'd be hesitant to dump your restructuring into dev. Obviously, however, the sooner you get code / issues up the sooner you'll get people to pitch in. I'm sure there are more knowledgeable people around who can give advice on that.

@Seanbfuller, with today's commit, the entity type abstraction for registrations is ready to be tested.

Very cool. Thanks! I'll grab the new code and start to dig in later today.

I just wanted to follow up on this. So far in simple testing the updated version is working great when dealing with nodes. I haven't gotten too far into testing with other entities though, since my use case required attaching registrations with commerce. Some of the improvements in this new version might have actually answered some of our needs so that we can go back to using nodes, however. (We're still exploring.) When dealing with commerce products it would require something similar to jpontani's commerce_registration module (mentioned in #16 above) to help bridge between the two. Obviously that's outside of the scope of registration.

I'll create tickets as I find any issues. Otherwise the improvements awesome! Thanks!

Cool, Sean. Commerce integration is on our very near-term radar, as we need it for three clients who are all contributing billable hours to the release of an abstracted solution. We're still a bit confounded by how we want to handle it though. Where are registrations handled? At the product node or the product entity? What's the user experience, workflow, etc.? It's definitely solvable and we're watching jpontani's work closely. Keep an eye on the queue and let us know what you think/experience.

Cheers,
Sean

I thought of that as well, and it seems best to do it by a product entity, whereas I assume by product node you mean product display node. The reason being (at least for my scenario) was that we wanted to know registrations for a specific product rather than a grouping of products (IE registration limit per product, rather than overall "event"). Example, we have two registrant types, student and non-student, with different pricing on each one, but have them on the same product display for the same "event". But we limit registrations on the non-student product but not the student product. Setting a registration on the product display does not allow for this capability.

I actually had planned to create a new branch on my Commerce Registrations to adapt it to the new Registration setup rather than my own Registration modifications.

@JPontani, makes sense, but on the flip side, that means that you have to manage interactions with two groups of registrants for a single event. For example, if you wanted to use the broadcast email tool that ships with Entity Registrations, you'd have to go through that process twice - once for the student group, and then the non-student group.

Managing separate registration limits shouldn't be too hard in a few lines of custom code. And you could key off a field on a product entity.

I think that the larger issue is whether or not different "types" of registrations have different fields. Do the students and non-students fill out different registration forms? If so, then that would be a good reason to have the registrations tied to product entities, rather than product display nodes.

The other option, which we haven't explored, would be some sort of glue code to connect registrations to /both/ event nodes and product entities...Dunno.

In this scenario, they do have different fields (students have additional fields or fields that non-students wouldn't need to fill out, ie: student id number).

In regards to the broadcast email, it's not as lengthy as you might think. On the event node you simply check the products that are attached, and can then send an email out to all registrants for all products on that event, or develop it so that the email form has a selection list of either "send to all registrants", "send to product A registrants, or "send to product B registrants". Provides flexibility in case you want to have slightly different emails depending on the registrant's product that they purchased.

I've gotta chuckle to myself, because I think that by pushing this thread I'm gonna make Lev want to pull his hair out - as he's the one who's going to have to write most of this code....

But I did have a thought - which was to switch the order of operations around and consider actually attaching the product entities to the registration entities (rather than attaching registration entities to products...) You could manage the different registration fields with something like conditional fields. You might even be able to switch product entity bundles based upon this switch on the the registration.

There are a couple of benefits to attaching products to registrations vs the other way around. We could create some sort of paid registration "state" property that allows you to register for an event (ie, hold a spot) prior to checking out (ie, purchasing the product entity). Then, in custom code or rules integration or session handling or whatever, you could expire that "hold" if the user doesn't complete the checkout process in some fixed amount of time.

I'm just spitballing here. Probably not the right place for this thread, and again, I need to defer to Lev re: implementation issues. I'm just a PM with a dangerous knowledge of the entity system. ;)

For our use case: We have products that are events to which registered users can pay to sign up. We also have some users/roles who can register at no cost.

The solution we are currently moving forward with: I've got a small custom module that is using a form alter hook to add the registration fields into the add to cart form (after an initial click). We then hijack form submission to go to a custom function that saves the registration before passing back to commerce submission. Part of the reason we went this way was due to the complexity around commerce's add to cart form. Next steps include adding some rules (based on jpontani's work) for when a commerce transaction is complete. It looks like we'll have event info and registrations tied to nodes, so we will also need to ensure that we can look up the node from the product info. I'm hoping that's still in context at that point, but I need to dig into rules a bit more to see what I have to work with. Our situation might be a bit too specific to be the final way forward, but I thought I'd share anyway.

In thinking through this, one of the elements that seemed to stand out was the status of a registration. I wonder if pulling that chunk of functionality out into it's own module (registration_status) would allow for other applications also (wait-listing, etc.). Then the glue module for commerce and registration would be able to leverage it also.

Just some random thoughts that might help push some elements of this conversation to the right thread. :)

Very interesting thread, if not slightly confusing. Several different forks/patches/branches, with a lot of overlap. It's incredibly hard at this point for someone who stumbles acros this module in search of a decent solution for a DC paid event registration system, to know what to install, patch, and test!

As far as I could make out, it seems like some, but not all, of jpontani's changes from http://drupal.org/sandbox/jpontani/1307874 have been incorporated here. It's not clear wether his Commerce Registration sandbox is still relevant or if it can be used in conjunction with the latest Registration code.

Also hard to know wether I should be attaching Registration types to Nodes or Products, or attaching Products to Nodes or Registration Types!

I'm confused!

Can someone a little more 'in the know' summarize where we are at?

@mrfelton
Some of the changes have been implemented, yes that's true. There are some things also in my version that were things I added to it that could be relevant and helpful to others, but the initial drive behind doing it was because I needed it for my project.

My Commerce Registration sandbox would most likely not be applicable in its current form of this Registration module. It uses some hooks and other registration functions that only exist or are in the context it needs inside my registration sandbox. I have a 7.x-2.x branch started that will be refactoring as well as reapplying the same code and workflow to use the latest version of Registration.

As far as where to attach registrations, that completely depends on what your requirements are.

This thread is confusing and doesn't seem to accomplish anything in terms of forwarding the progress of the module as per the title. Despite the title it focuses on Commerce Entities as opposed to (Arbitrary) Entities of all types. I have posted a new issue here #2318529: Suport local task support for other types of entity to try to refocus it.