Integration with Inline Entity Form

Duplicate #1650182: Make registration settings available from inline entity form?

The duplicate #1650182: Make registration settings available from inline entity form has been bumped to 'Commerce Registration.' So re-opened this issue as I think this is quite a reasonable step forward in UX to incorporate inline entities

I understand the use case for inline entity form for Commerce registration, but I don't understand it for Entity Registrations. Could someone please explain the issue? The workflow is very simple right now. On the host entity, you choose a registration bundle. That adds a "manage registrations" tab with a number of local tasks. Are you looking to add all that data to the host entity's edit form? If so, I don't agree that that is an enhancement.

Entity Registrations is very intentionally a tight module with as few dependencies as possible. (We don't even require the Date module.) It would take a pretty strong argument to add a complex dependency like IEF - and I'd argue that it makes the ER more fragile rather than less.

From a content editor's perspective, they would want to create the entity and it's associated registration settings in one go. A 2 step process is just not that great a solution: filling out one form, saving it, then going in to subsequently edit another form [the registration settings via a the newly-saved entity's tabs] is just cumbersome. Non-tech users won't really be interested in Drupal's underlying architecture, or be impressed by how tight a module is... they just want an appropriate UX.

The ideal solution would be as soon as the the Registration type is selected, either some sort of pop-up, or inline form is presented to the [editing] user to populate the Registration Settings. And if the parent entity has a default relationship type, then the relevant registration settings should be 'there.' I'm not saying make IEF a dependency, but it would be useful as an optional, integrated UX enhancement.

If this seems an unreasonable request, or something that is far too complex a technical feature, then 'Close' this issue.

Why would you burden an editor with settings for each entity? Why not have sensible defaults?

That's a reasonable point, but far from a universal solution... you'd have to generate a message prompting the user (content editor) to check that the registration settings [as generated by the default] are OK... because the user may not even realise that those settings actually exist. It's one of the golden rules of interface design: locus of control. A discrete 2nd step is not giving the content creator full control over what they are doing. If they are creating an entity that depends on registration, then the paramaters controlling that registration are fundamental to the context of that (parent) entity.

I fail to see how the current 2 step process is better than a single, transparent step. The node edit form (after an initial save) is ideal in that 'Registration settings' are in a collapsed fieldset and this visual hierarchy is appropriate to the importance of the registration: subtly demoted from the parent entity's fields, but accessible. And the user is in control. The form should be similar to this at initial entity creation, and up to the site builder/themer to design an appropriate visual hierarchy regarding fields and field groupings.

IEF just seems (so I thought) a simple solution that shouldn't add major bloat or duplication to ER. I don't quite understand how IEF works with other entity references, but from a site-builder's perspective it is a simple implementation that should work well for end users. However, judging from tone of the comments from the module maintainers, it would seem that this is not such a simple solution to implement... and the more I think about it, the current architecture of ER would mean the IEF would only be able to generate another Registration Type, rather than an instance of a Registration Type.

Arrgh, thank you for explaining your feature request. As you point out at the end of your message, IEF isn't applicable, given ER's architecture. Registration settings on a host entity are not stored as a separate, referenced entity, so this just won't work.

I agree that the ER architecture needs to change if this is the case. What is the point of making registration a field if I can only have one per entity?

@jason.fisher, using a field enable registrations an a parent entity has proven to work really well. Reviewing the code/architecture might provide more insight.

I see two unrelated issues being discussed here. The first, as initially proposed, is to use IEF to embed the registration form within a parent entity. This is handled quite simply already via a field formatter, so I don't see a win by relying on IEF instead.

The second is merging the registration settings into the parent entity's add/edit form. This very unlikely to happen; the settings are not even an entity and there are many other reasons, including granular access control, to leave them where they are.

The second is merging the registration settings into the parent entity's add/edit form. This very unlikely to happen; the settings are not even an entity and there are many other reasons, including granular access control, to leave them where they are.

Checkout Drupal Commons and the Commons Event module. I think this is what a lot of people want to have.

Ref #6

Why not have sensible defaults?

Whilst this is a perfectly valid comment, it is fair to say that some settings do not always lend themselves to being defaults. The capacity value is one such item.

I think that exposing the capacity field alongside the Registration Type Widget would be a huge improvement in the usability of the module. One form to complete and job done in most cases - leaving a review of the additional settings as an 'only if necessary' task.

Please don't reply hook_form_alter, I really haven't a clue what you are talking about:-)

Ref #10 @levelos

The second is merging the registration settings into the parent entity's add/edit form. This very unlikely to happen; the settings are not even an entity and there are many other reasons, including granular access control, to leave them where they are.

Could I make an additional case for the facility to configure registration settings upon node creation? The use case is for organisations operating a large number of registration entities based on repeating dates.

I expect that the majority of those using the registration module incorporate a date field. I would also go as far as saying that not using a date field probably represents a niche use case rather than the norm.

A number of modules now provide the facility to clone entities based on a repeat date pattern. Separate nodes are of course a pre-requisite for collecting registrations, making this formula a natural fit for Entity Registration.

The problems start when it comes to configuring the registration settings. Building sites for organisations with many different events, posted by different event co-ordinators, with different capacities and sometimes with different conditions, I am faced with a choice between needing to re-configure the content type for each instance, which is a bit tedious and not something I would want, or could expect an editor deal with. Or needing to create a new content type every time an event comes along which calls for different registrations settings. Capacity is the main thing, by a mile, but the other settings matter too.

To be clear, I am not making a request for better date integration. That Entity Registration is not dependant on the date module is of course a good thing. But I do ask for improved registration setting management at the time of node creation, whether this with an inline entity form or field formatter or something else.

As I mentioned in the post before, just having the capacity field available would make a huge, massive difference.

I join the discussion because I agree with the request.

Actually, the module is not flexible enought to be usable in most case. When the website administrator is the creator of the events, it can do the job as you can create the registration type to fit your need and then, create the node that will embed that registration. It can be ok.

But when you have to deal with a website that allow users to create events (for my example, a cooking website where users can create cooking training), each user have their own registration rules. Some people will have 10 spaces of capacity, some others just 5, some users will want to activate the wait list, some not....

You can't create all possible case in advance and let the user choose the registration type in a huge list, it would be hard to configure, hard to use for users... useless. So, what you can do ?

When you create a new registration field, you should be able to choose between 2 modes.

• The current one called "Global settings" that will allow you to define the registration settings on the field level
• A new one called "Per node settings" that will allow you to define settings when you create the node

With that 2 different modes, this module should cover most of the case. Actually, it doesn't cover half of them.

Reopen the issue cause the original request is still avoided.

To make it simple, some people needs to be able to edit some settings when they create the node that contains the registration field. They no just want to choose between different registration type, they want to alter a specific registration type setting on the node level because options like capacity, spaces etc... can change everytime and defining them when you create the entity is not a good solution for most cases.