- 🇬🇧United Kingdom adamps
With 2.x Mailer classes can be registered for any tag (including multiple dotted parts) so I feel we can finally close this.
Automatically closed - issue fixed for 2 weeks with no activity.
In
✨
Allow EmailBuilder plugin not linked to module name or config entity
Fixed
it was stated, that EmailFactory supports having different mail builder classes for every in a given module. Specifically:
Did you try to create an EmailBuilder for a sub-type? If you look at EmailFactory::initEmail() then there is some code in this direction: it searches for a plug-in name based on the "suggestions" - which means first TYPE_SUBTYPE then TYPE. Probably this code has never been tested. I would welcome patches that fix it.
In a custom module (e.g., custom_lesson) add multiple email builders with the following ids:
custom_lesson.applicationcustom_lesson.approvalThis roughly implements the use case given in the other issue. I.e.:
The module provides a simple form where a (anonymous) visitor enters their email address, to be added to the waiting list for a lesson (= product variation entity). They get a confirmation message about that, and a "waiting_list_entry" content entity gets created.
So here my EmailBuilder only receives the lesson parameter.Afterwards an admin user can send an email message to a waiting list entry entity (like "Hey, a new spot is available").
This EmailBuilder needs to receive the waiting_list_entry entity parameter.
Regrettably a module set up like this will not show up in the policy drop-down. I guess this is because EmailBuilderManager::processDefinition populates the sub_type field instead of the sub_types field of a definition.
Fixed
1.0
Code
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
With 2.x Mailer classes can be registered for any tag (including multiple dotted parts) so I feel we can finally close this.
Automatically closed - issue fixed for 2 weeks with no activity.