@Hviid there's an example of using multiple email backends in the Djrill docs.

Can you provide an example of what you're trying to do that isn't working? What relevant settings.py options have you changed to try to make this work, and what code are you using to send mail? People here can probably help if you provide some specific detail.

from djrill.

Really really sorry, don't know how I missed that. That's exactly what I'm looking for.

from djrill.

Hmm, seems like it's only possible to exchange the AdminEmailHandler in Django 1.6.
https://docs.djangoproject.com/en/1.6/topics/logging/#id3

from djrill.

Another option (which should work in all Django versions) is to leave your default Django EMAIL_BACKEND set to 'django.core.mail.backends.smtp.EmailBackend'. (Don't change EMAIL_BACKEND to Djrill in your settings.py.) This will cover admin messages -- all messages actually, by default.

Then in the specific places where you want to send mail using Djrill, use the connection override to specify the Djrill backend:

djrill_backend = get_connection('djrill.mail.backends.djrill.DjrillBackend')
send_mail("Thanks", "We sent your order", "[email protected]", ["[email protected]"],
          connection=djrill_backend)

One of my projects achieves something similar by using the django-mailer mail queuing package. We set django-mailer's MAILER_EMAIL_BACKEND to Djrill (so that all mail through django-mailer uses Djrill), but leave Django's default EMAIL_BACKEND set to SMTP for admin messages. Then we make sure to send customer-facing messages only through django-mailer.

from djrill.

@medmunds, how you handle unit testing mail.outbox count when using your approach?

from djrill.

@gabrielprat I think that's more of a django-mailer question than a Djrill question (sorry if I'm misunderstanding). But here's how we handle it...

django-mailer queues outgoing mail. So each email test case needs to release that mail queue into Django's test email backend before checking the outbox count. Example:

from mailer import send_html_mail  # this is the django-mailer queued version

class EmailTests(TestCase):
    ...
    def someTestCase(self):
        send_html_mail("Test", "foo body", "<b>foo html</b>", "[email protected]", ["[email protected]"])
        self.sendQueuedMail() # release the queue into the test outbox -- see below
        self.assertEqual(len(mail.outbox), 1)
        message = mail.outbox[0]
        self.assertStringContains(message.body, "foo", msg="Plaintext should include foo")
        ...

sendQueuedMail is a method we define for our EmailTests. It overrides the django-mailer MAILER_EMAIL_BACKEND with the test (locmem) backend, and then flushes mail from django-mailer's queue into the test mail outbox:

    def sendQueuedMail(self):
        """If we're using django-mailer, "deliver" any queued messages into the test backend's mail.outbox"""
        if "mailer" in settings.INSTALLED_APPS:
            # override django-mailer's backend with the Django test backend:
            settings.MAILER_EMAIL_BACKEND = 'django.core.mail.backends.locmem.EmailBackend'
            # dig into django-mailer's internals to invoke the send:
            from mailer.engine import send_all, EMAIL_BACKEND
            if EMAIL_BACKEND == 'django.core.mail.backends.locmem.EmailBackend':
                send_all()
            else:
                # Let's don't accidentally send real mail from a test case
                raise ImproperlyConfigured("Test case is trying to use real email backend: %s" % EMAIL_BACKEND)

The code above was written against a really old version of django-mailer, so may need some tweaks to work with later changes. (In particular, "dig into django-mailer's internals to invoke the send" is probably affected by pinax/django-mailer#19.)

from djrill.

Thanks for your reply @medmunds, on my side I'm not using the same approach as my test simulates a request for a user creation with an email automatically sent on this action by the view.

So, after a fine tuning and a small refactor, I've achieved to switch back to a "standard" settings with just my EMAIL_BACKEND setting pointing to the one provided by Djrill, and now the tests are working as expected, I've did not went into detail about why or why not before since I don't need to user 2 different connections at all :)

So sorry if the following is an OFF-TOPIC but I don't know where to ask.
How can I get the mandrill response msg._id for every message when sending emails as bulk using an approach as the following:

    for recipient_email in to:
        # I perform some controls and register some info about the user and email address
        msg = EmailMultiAlternatives(
            subject, text, from_email, [recipient_email])
        msg.attach_alternative(html, 'text/html')
        messages.append(msg)
    return connection.send_messages(messages)

I guess that this is somewhere documented but I've been digging around with no success :(

Thanks in advance,
G.

from djrill.

The send_html_email in my test case above is an example -- you can (and should) substitute whatever code you want to test that would cause an email to get queued.

Mandrill's message id is covered in the "Mandrill Response" section under "Sending Mail" in the Djrill docs.

If you have other questions, I'd encourage you to either:

• Open a new issue if it's a different topic (helps other people searching the issues later)
• Ask on Stack Overflow (I monitor questions tagged both "Mandrill" and "Django", and you'll get the benefit of thousands of Django experts if your question turns out not to be Djrill-specific).

from djrill.

Hello @medmunds , just FYI -> http://stackoverflow.com/questions/30071473/how-to-get-mandrill-response-for-every-message-when-sending-html-bulk-emails-wit

from djrill.