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?