As designed Allow activity summary test emails with $config['enableMail'] = false

[Mouth]

If a DEV/Test environment of xF has $config['enableMail'] = false; within it's config.php, still allow sending of test emails ( /admin.php?activity-summary/ and /admin.php?tools/test-email ). This will allow testing of email systems without having to allow global sending of emails or utilise workarounds.

 

[Paul B]

It's worth pointing out that the test email function still works with email disabled in config.php.

It's just the activity summary which doesn't.

 

[Chris D]

Not technically a bug but I think we'll change this and we'll move to bugs to track it there.

I should note that admin.php?tools/test-email isn't actually affected by the enableMail flag - when set to false test emails are still sent, so there is an inconsistency here.

 

[Paul B]

An addendum to the original bug report, if the feature is unchecked and a test email is 'sent', although there is a positive confirmation message, no email is actually sent.

Ideally it would be possible to send a test email even if the feature is disabled (rather than disabling the test email functionality).

 

[Chris D]

OK. We actually don't prevent sending activity summary test emails either... so nothing to do there.

An addendum to the original bug report, if the feature is unchecked and a test email is 'sent', although there is a positive confirmation message, no email is actually sent.

Ideally it would be possible to send a test email even if the feature is disabled (rather than disabling the test email functionality).

We've made a change here though it isn't necessarily retroactive as it involves setting a default value once the option is disabled. You'll be able to toggle the option on/off to get the same effect and then after that, test emails can be sent even if the option is disabled.

 

[Mouth]

OK. We actually don't prevent sending activity summary test emails either... so nothing to do there.

I'm not sure that's true? Using 2.2b5, and changing src/config.php between utilising /admin.php?activity-summary/send-test-email ...

//$config['enableMail'] = false;
//$c->extend('mailer.transport', function()
//{
//    return \XF\Mail\Mailer::getTransportFromOption('file', [
//        'path' => \XF::getRootDirectory() . '/internal_data'
//    ]);
//});

... email is sent and received by mail client (Gmail)

$config['enableMail'] = false;
//$c->extend('mailer.transport', function()
//{
//    return \XF\Mail\Mailer::getTransportFromOption('file', [
//        'path' => \XF::getRootDirectory() . '/internal_data'
//    ]);
//});

... no email is received by mail client

$config['enableMail'] = false;
$c->extend('mailer.transport', function()
{
    return \XF\Mail\Mailer::getTransportFromOption('file', [
        'path' => \XF::getRootDirectory() . '/internal_data'
    ]);
});

... email is deposited into internal_data/*.eml file

 

[Chris D]

Setting the transport via config.php actually overrides the enableMail switch apparently. I had no idea

So something we still need to look into but that does explain why emails are written out locally even if enableMail is false.

 

[Chris D]

Ok, unfortunately I'm not seeing a great way to workaround this without potentially fairly extensive changes or some weird special cases and I'm not sure that's the right thing to do.

By default if enableMail is set to false then we force the default mailer transport to use a NullTransport adapter. In other words any email we try to send is sent "successfully" it just doesn't go anywhere.

This is somewhat of a necessity because it allows the email system to function as normal on the surface without generating errors in our various places that we use email and without us having to detect on a case by case basis whether emails should be sent or not - which may leave scope for accidental cases where emails are sent when they shouldn't be.

The behaviour of the config.php mailer.transport override actually works in our favour though. Because this essentially changes the NullTransport transport adapter to be whatever you define there, it provides a decent way of overriding the behaviour for testing purposes, if desired and serves as a reasonable workaround for now.