Register an entity different than a user

Sounds like a very interesting/promising concept.

It is probably too late for v1, but making anonymous users their own entity and simply relying on an entity relationship for $registration->user would be the way to go.

@dpi, what benefits do you see in making anon users a new type of entity? I see one clear benefit of adding configurable additional fields to anonymous registrants that you wouldn't want to collect for authenticated users. That said, if other anon fields are needed, I imagine we could come up with sensible defaults.

I'm also looking to accomplish the same thing.

Or to have a user register themselves and their companions, adding multiple entries as needed. Similar to how if the image field of an Article content type is configured to allow multiple values, in this case multiple entities with their respective fields like email, full name, age or whatever.

Yes, I'm looking for something similar for a primary school.

I want parents (users) to be able to register their very young children for after school clubs. The children are neither users, nor do they have email addresses and some of them are still in nappies (diapers)!

Yes I could attach a text field to the registration where the children could be named, but this is rather impersonal and will quickly become tedious for multiple registrations. Ideally I want users to register individual field values which are associated with the user's account or their profiles.

Any workaround tips in the meantime would be most appreciated.

I am wondering whether the Subuser module could be a viable solution for this issue.

A important point is that the registration module allows a user to register any other user's subusers which in many cases would be undesirable.

I have put up a feature request for the subuser module, but it would probably need input from the Registation devs

See https://drupal.org/node/2172431

Update on the school, parent, child thing.

Firstly, I looked at the Subuser module and for various reasons thought that it wouldn't work out very well. Mainly because sub-users still need an email address and also because sub-users could go on to create other sub-users which didn't seem a good idea. Moreover, the module did not appear to be very actively maintained.

I have had good success though by creating a basic content type called 'child' which uses the title field for the child's name. The parent (role) has permission to create a child and the two are naturally linked because the parent is the author of the child.

I made this work for Entity Registration by creating a content type called Registration Activity and including a registration field which was based on a field collection which includes an entity reference of child nodes. I employed the content access module to ensure that children's records could only be viewed by the parent and admins; this also had the neat effect of parents only being able register their own children, but admins can register any.

I am using the parent/child metaphor, but more generically this might be registrant/attendee or user/associates

So here goes.

- Create a parent role.
- Create a content type called Child and set permissions allowing a parent to create a child. The title field is the name of the child.
- Use the Content Access module to apply further permissions to the Child content type, allowing view/edit access for own content, but denying access for all others except admins.
- Create registration type called 'Parent registers child'
- Add field collection to the registration type called 'child';
- In the field collection, add an entity reference, using the simple method, and set the target bundle to child. Set number of values to unlimited.
- Create a content type called registration activity and include a registration field of type 'parent registers child'

The result is a normal registration node were the registrant must still select the number of slots required; however there is a second field which is populated by the parent's children from which the parent may select which of their children are attending, (admins see all children allowing them the option to register any child). After trying out a few selection widgets I settled on the Chosen module because of it's ease of use. I don't code, but ultimately it would be great if the number of slots could be automatically determined by the number of children selected. A big hint for any dev types reading along:-)

Regarding the bookings; the default Registrations list, appended to the node will still only show the registrant and the number of spaces booked, so it is necessary to create a view of attendees. This view will be of registrations by host ID, with relationships for the attendees and some other values

NOTE: Whilst it is a normal Drupal approach, I have since realised that a child content type is probably has some limitations for developing other relationships beyond that of the author. I am therefore going to rebuild this general idea around a CRM module. This approach may also simplify some of the permission requirements. For compatibility reasons I will look first at RedHen as this maintained by the same developers.

With thanks to @lklimek Łukasz Klimek starting me on the right track via the Google+ Drupal Community

This functionality exists in the Registration 2.x branch, where you can register any entity that has an email address property or field.

Re-opening for possible addition to the 3.x branch. Will look at 7.x-2.x implementation.

Hi, I maintain the Event Registration module. Based on conversation with the Member Platform and CRM teams, I wanted to take a pass at porting over some of my dynamic registration functionality, which allows this requested feature for entity registration, in order to consolidate work and implement a single solution for registration.

I took a rough first pass at this implementation (available here). This takes a first pass at replacing the user_uid field that tracks the registered user with an entity reference with can be configured based on the registration type. The changes in the branch include updates to the Entity Types, the replacement of the getUser and getUserId functions across the code base, and update hooks to move the existing user registrations to the new field. We still need to work on replacing additional references user_uid field across config and the code as well. Additionally the concept of registering a user is ingrained into the module's functionality, so this will require reworking many areas including forms, routes, and other functionality.

Given the amount of work that will be required, I expect we may want to consider a new 4.x branch series for these updates, since it will likely break sites.

There are a few thing to cover in the long term, that we will want to review. The first of which is how to support anonymous registration. I did this by falling back to profiles, which can be created by anonymous or signed in users. Adding the dependency to the module isn't ideal, but it did meet my needs in event registration. The main question is how to handle the existing data. For example, we can easily link registered users, but will need to implement a process to copy and store the anonymous email address. I like the idea of moving that off the registration record itself, as registrations might not be for organizations with emails (who knows maybe this could be used to register api callbacks or something that doesn't have an email?) if we are trying to keep things generalized. Open to further discussion as we move forward.

Hi Rich, thanks for taking this on, and I'm happy to assist in any way that I can. I'd like to learn more about your desired end state so I'll try and connect with you on Drupal Slack within the next few days. I agree that due to the scope of the changes, this should likely be part of a 4.x dev branch. Talk soon.

Thank you to Rich for taking this on!

John, not sure whether you're available but I'd like to invite you and anyone else interested to the Member Platform meeting tomorrow, Nov 20 at 10am CST at https://us06web.zoom.us/j/84872142777?pwd=D4zZg43qW0Gn4L5KaaNnh7ub8YT2PV...

Please join us in Drupal Slack's #member-platform: https://drupal.slack.com/archives/C07RLHPTSUR

Thank you I joined the channel and should be able to make the Zoom

Just a quick note while I'm thinking of it that, for CRM's use case of CRM Contacts being registrants for an event, it would be important to be able to restrict the entity bundles that are permitted to be registrants (e.g. only CRM Contacts of bundle Person can be registered using a given Registration Type). It would also be desirable to support a mix bundles + registrations for non-entities (e.g. someone's +1 for whom we don't have enough information to create / require creation of a CRM Contact entity).

We discussed approach for this, and decided that it would be best to implement this as a submodule (something like registration_entity), as to be as non disruptive as possible.

The new sub module would take care of providing the additional field from "registered entity" and controlling the visibility/access of the existing user_uid and anon_email fields, so that we can support both.

I think likely we'll need to do the following:

• provide a new register able entity field
• allow selection of entity to register
• Provide an api for controlling available register-able entities (likely by providing a new "register" access operation, which can checked in hook_entity_access
• allow selection of which registration types are for "users" vs "Entities"
• allow selection of which entity type(s) should be register-able
• prevent display of the registration type drop down
• prevent display of the email field for anon users.
• ensure that email functionality supported by base module is not broken for new entities
• Optionally: provide a way to proxy email value for registered entity, to another field on registered entity, via a referenced entity or token.

Thanks @richgerdes, your latest post makes sense to me.