Implement full integration with ECA module

Hi,

The token code we created is necessary to get access to the various things like the dates registration is open, the close date, etc.

We're using it with ECA to make it so a user can edit or delete their registration up to the close time -- and after the close time, ECA prevents them from making any changes to their registration. Our client had had some instances of people deleting their registrations after an event to avoid payment (this client is not using commerce...)

For most of the things we want to do, access to the host entity is necessary, so that's what the token code adds... Otherwise ECA works with registrations already, since it has full support for entities, fields, forms, views, etc.

Cheers,
John

Hi,

Was just going through this module -- we have an automatic importer that creates an event every day -- but also a "restrictions" system that allows admins to create date restrictions. We were trying to hook this up using ECA to find events that already exist when a restriction is added, close registrations for that event, and notify the admin if there were any existing registrations. And found this just about impossible!

I added our previous code from ✨ Integrate with Rules module including host entity methods Active -- but that gets you a token for registration_settings (host entity) from a registration, NOT from the entity that the host entity is attached to. So I dug in trying to find how to get a host entity/registration settings from a node it's attached to --only to find it doesn't exist until somebody registers or changes the settings. Am I understanding this correctly?

If so, I'm thinking this is something we need -- a method added to the RegistrationManager that fetches an existing registration_settings entity if it exists, or creates it from the entity type/field settings if it doesn't. I'm thinking if this is added as a service, it can be maintained through whatever changes come from ✨ Allow admins to change host entity for existing registration Active and ✨ Establish host variations as an architectural concept Active , and would be generally useful for anyone trying to integrate this from other modules.

And then add an ECA action plugin that calls it to load a RegistrationSettings entity that could then be interacted with using normal content entity conditions/actions.

Are there other scenarios that need to be considered? I'm thinking what we're talking about would be

• Action: Load Registration Settings from Entity -- I guess this could also just be a token, [node:registration_settings] - or [node:field_registrations:entity] or whatever makes the most sense.
• Token: [registration:host_entity] - entity that a registration is associated with
• Token: [registration:registration_settings] - registration settings entity associated with a registration

There could certainly be other convenience actions and conditions, but really all that's required at a baseline are making some tokens work...

Thoughts?

@freelock you are correct that settings are not automatically instantiated (saved to the database) for host entities. Doing so would cause many issues including making it more difficult to change the default settings later. However the host entity object already has the getSettings call that you propose for the RegistrationManager, so another function is not needed. Example code assuming a node is the host:

$handler = \Drupal::entityTypeManager()->getHandler('registration', 'host_entity');
$host_entity = $handler->createHostEntity($node);
$settings = $host_entity->getSettings();

Alternatively, if your site is multilingual:

$settings = \Drupal::entityTypeManager()->getStorage('registration_settings')->loadSettingsForHostEntity($host_entity, $langcode);

The following code is not necessary, but if for some reason your use case requires that a settings entity exist in the database prior to the host having a registration or prior to settings being saved through Drupal admin, then you can do this. This is in fact done in the postSave for the Registration entity.

if ($settings->isNew()) {
  $settings->save();
}

Your proposed ECA Action still makes sense to me though, it just doesn't need a new API function to be created.
I do not know enough about ECA to comment on the Tokens you proposed, but they seem logical.

I hope this helps, happy to clarify further if you have more questions.

PS - Looks at the tests folder in the Registration module - lots of goodies in there showing how entities can be fetched and manipulated.

$handler = \Drupal::entityTypeManager()->getHandler('registration', 'host_entity');
$host_entity = $handler->createHostEntity($node);
$settings = $host_entity->getSettings();

Alternatively, if your site is multilingual:

$settings = \Drupal::entityTypeManager()
  ->getStorage('registration_settings')
  ->loadSettingsForHostEntity($host_entity, $langcode);

Any reason why not this for multilingual:

$handler = \Drupal::entityTypeManager()->getHandler('registration', 'host_entity');
$host_entity = $handler->createHostEntity($node, $langcode);
$settings = $host_entity->getSettings();