Using Craft module variables in Notifications stopped working

[medoingthings]

Describe the bug

I use variables from a custom Craft module to pipe a set of information into a notification. This stopped working with the update from Craft 4.8.9 to 4.8.10 and is still present in the most recent release Craft 4.8.11.

The setup looks like this:

Formie log says:

2024-04-30 16:11:00 [INFO] Submission triggered for inhouseInvitation.
2024-04-30 16:11:00 [ERROR] Error parsing template: “{craft.paragrapheinsModule.getInhouseInvitationParts(relatedTrainingDate.one())['subjectInvitation']}”: “Calling "one" method on a "craft\elements\db\EntryQuery" object is not allowed in "__string_template__d6eff513ad4b25b7ce1a92cededac9e7" at line 1.” /Users/medoingthings/Sites/paragraph-eins/cms/vendor/twig/twig/src/Sandbox/SecurityPolicy.php:105
2024-04-30 16:11:00 [ERROR] Error parsing template: “<p>Hallo,</p><p>wir freuen uns darauf, Dich am <strong>{craft.paragrapheinsModule.getInhouseInvitationParts(relatedTrainingDate.one())['fullDate']}</strong> zum Training „{craft.paragrapheinsModule.getInhouseInvitationParts(relatedTrainingDate.one())['trainingTitle']}” zu begrüßen. </p>”: “Calling "one" method on a "craft\elements\db\EntryQuery" object is not allowed in "__string_template__136958cd1becf1c5188982ac20076338" at line 1.” /Users/medoingthings/Sites/paragraph-eins/cms/vendor/twig/twig/src/Sandbox/SecurityPolicy.php:105

Since the error is introduced by Craft I wasn’t sure where to report the issue. Because the problem surfaces in Formie and you might have a better understanding of what’s wrong, I thought this might be the most efficient path to take in resolving this.

Steps to reproduce

1. Run Craft 4.8.10
2. Use a module variable e.g. in the subject line.
3. I think the issue is related to having an entry query as a parameter: {craft.paragrapheinsModule.getInhouseInvitationParts(relatedTrainingDate.one()) The variable relatedTrainingDate is an entry field in the form configuration.
4. Trigger the notification by submitting the corresponding form – this should result in an empty notification subject line.
5. Try the same with Craft 4.8.9 – it should result in a subject line with what the method returns.

Form settings

• Multi-page form: No
• Submission Method: Page Reload
• Client-side Validation: No
• Custom Form Templates: No

Craft CMS version

4.8.9 (works) 4.8.10 (error is introduced)

Plugin version

2.1.13

Multi-site?

Yes

Additional context

No response

[engram-design]

This probably has to do with restricting Twig functionality due to some security concerns we're using a sandbox with limited functionality, but it is strange you mentioned this is working on 2.1.13 and it's a Craft version that's triggering things.

I think in this case you might need to register a new variable via PHP, rather than writing Twig. It's probably our preference as well, as the whole concept of Formie is to keep things friendly for novice users (even if this form might just be for yourself).

use verbb\formie\helpers\Variables;
use verbb\formie\events\RegisterVariablesEvent;
use yii\base\Event;

Event::on(Variables::class, Variables::EVENT_REGISTER_VARIABLES, function(RegisterVariablesEvent $event) {
    $event->variables['custom'][] = [
        'label' => 'Custom',
        'heading' => true,
    ];

    $event->variables['custom'][] = [
        'label' => 'Entry Title',
        'value' => 'Some Example Title',
    ];
});

Here, this adds a new option to the variable-picker dropdown of your choosing. Now that might be tricky considering you want some context of the form you're currently on, so that might not work for you.

As an alternative, you can keep the Twig that you have now, but add some exceptions to the Twig Sandbox to allow some things.

use craft\elements\db\ElementQuery;
use verbb\formie\Formie;
use verbb\formie\events\ModifyTwigEnvironmentEvent;
use yii\base\Event;

Event::on(Formie::class, Formie::EVENT_MODIFY_TWIG_ENVIRONMENT, function(ModifyTwigEnvironmentEvent $event) {
    $event->allowedMethods[ElementQuery::class] = 'one';
});

Here, we state with class and methods to allow. You might even need to add your module's method. I know that's a bit more of a pain, but it's a pretty valid security concern if we allow any Twig to be written in fields, as it can be very easily exploited. So most advanced things are opt-in.

Refer to the docs

Both of these events will be available for the next release. To get this early, run composer require verbb/formie:"dev-craft-4 as 2.1.13".

[medoingthings]

This is great, thanks!

Variant 1)

This is really useful. I would love to use this way, but as you stated, I would need the context. Is there any way that I can refer to the values from the submitted fields? Or the submission ID at least, so that I can query for the submission and get the entry value from it?

This would be a very user friendly way to use those custom variables instead of the inline Twig code.

Variant 2)

Used that one for the moment and this works great:

Event::on(Formie::class, Formie::EVENT_MODIFY_TWIG_ENVIRONMENT, function(ModifyTwigEnvironmentEvent $event) {
        $event->allowedMethods[ParagrapheinsModuleVariable::class] = 'getinhouseinvitationparts';
        $event->allowedMethods[ElementQuery::class] = 'one';
      });

[engram-design]

The reason that EVENT_REGISTER_VARIABLES has no context is that the values are static, but I can see what - if anything - we can do about that.

[medoingthings]

That would be pretty neat, because the most useful variables that are selectable in the drop down are dynamic values from the populated form fields. Thanks for the effort!