Right now the registration is only for entity types User.
The feature request is to enable registration for entity types diferent than User.
For example a content type attendant could be defined from entity type Node.
This way there is far more flexibility to define different type of registrations.

Comments

dpi’s picture

Sounds like a very interesting/promising concept.

dpi’s picture

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.

levelos’s picture

@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.

hatuhay’s picture

For example, I have a assitant from one company who needs to register 4 people from their staff.
The assitant is a USER entity on the system.
We create (or do Feature) a simple NODE entity type call Attendee.
Now she will to create 4 Attendees (Node Content Type Attendee) and will register them (can be triggered to automatically registration), including email field as a requiered one.
This is way more flexible.
On the other hand, if you choose entity type User it will handle as usual.

elpino’s picture

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.

seanberto’s picture

Title: Register an entity diferent than a user » Register an entity different than a user
MrPaulDriver’s picture

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.

MrPaulDriver’s picture

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

MrPaulDriver’s picture

Issue summary: View changes

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

gcb’s picture

Status: Active » Closed (outdated)

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

john.oltman’s picture

Version: 7.x-1.x-dev » 3.0.x-dev
Status: Closed (outdated) » Active

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