This change is a breaking change because it removes support for Python 2.x so a major release would be necessary.

The Django team suggests to drop support of Django versions prior to 2.2 in their release notes.

This will allow celery email to be fault tolerant to connection issues with the celery email backend.

Catching a connection issues allows celery to retry failed tasks. If the connection error is not caught an exception will be raised before the retry logic.

I have my configuration set up like this

EMAIL_BACKEND = 'djcelery_email.backends.CeleryEmailBackend'
CELERY_EMAIL_BACKEND = "djrill.mail.backends.djrill.DjrillBackend"

meaning that I use Mandrill to send mails.

In 1.0.4 I was able to set extra args on the EmailMessage object to use templates in Mandrill

email.template_name = 'report-{}'.format(get_language())
email.template_content = {}
email.global_merge_vars = {
    'CLIENT': Client.objects.get(slug=client_slug).name,
}

All versions after 1.0.4 no longer sends these arguments all the way to Mandrill

This supports the use of Celery's JSON serializer, which improves the security of Celery.

Prior to this patch, attempting to use Celery with the JSON serialization (as opposed to pickling) generated error messages complaining that a django.core.mail.EmailMessage is not JSON serializable. This patch converts email messages to dictionaries which are JSON serializable.

For those still using the pickle serializer, everything should continue to work the same.

Caveat on JSON-serializing attachments

This patch copies the attachments property of EmailMessages without further processing. Per [https://docs.djangoproject.com/en/dev/topics/email/#emailmessage-objects](the Django docs on EmailMessage objects), attachments are:

either email.MIMEBase.MIMEBase instances, or (filename, content, mimetype) triples.

As I understand it, this means that attachments as MIMEBase instances will still fail, but the triples may succeed. My application doesn't send attachments at the moment, so I haven't tested this. If in the deep distant future I get the opportunity to test it I will extend the patch.

Attachments will still work for those using pickling. In the mean time, this patch still enhances support for those using JSON - instead of everything failing, only a limited subset of things fail.

The Python 2 compatibility APIs are removed with the Django 3.0 release. Importing from djcelery_email.utils thus leads to ImportError: cannot import name 'six' from 'django.utils'.

Replacing django-celery dependency with celery as it django-celery is no longer the preferred way to integrate celery into a django project -> https://celery.readthedocs.org/en/master/django/first-steps-with-django.html#using-celery-with-django

This fixes the use of the deprecated execute_manager (not available in Django 1.3 and 1.6+).

It also adds support for Travis -- if you haven't heard of Travis, check out http://about.travis-ci.org/docs/

You can then add this cool build badge to your README file:

The latest commit also adds chunking and refactors the tests.

I'm sorry that the patch is so large, but it's all documented well and fully tested.

Tested on (see Travis): Django 1.2 to 1.6, Celery 2.3 to 3.1, Python 2.6 to 3.3 + PyPy

I am getting SMTPServerDisconnected('please run connect() first',) on some SMTP servers. I have no clue what could be wrong. For example GMail is working fine. When I move to my local provider I get this error. Do you think it could be a problem of django-celery-email?

Funny thing is, when I ommit EMAIL_TIMEOUT setting, those e-mails are sent in about 270 seconds or more! One by one ...

Messages with content_subtype overridden to "html" are sent as plain text when passing through djcelery.

It's because in the serialization process (email_to_dict function), only some attributes are copied.

Fix in https://github.com/pmclanahan/django-celery-email/pull/17

I know it's not a required setting, but it appears as though celery will just discard the tasks if this rate_limit is exceeded. In other words, if this is set, and you're exceeded the rate_limit sending emails, the emails will just get discarded which is probably not the behavior you intended.

Please correct me if I'm wrong.

For emails attachments contains a mimetype starting with text/, Django expects the content to be a string. This behavior is documented in here:

https://docs.djangoproject.com/en/2.0/topics/email/#emailmessage-objects

This causes both the email_to_dict and dict_to_email function to fail. email_to_dict fails because the attachment returned by Django is a string and not bytes, and dict_to_email fails because Django itself complains if you try to send an email with a text/* mimetype and a binary content.

This causes the a bytes-like object is required, not 'str' error to be raised at this line

I added workarounds to both functions and a regression test.

The pipelines on travis aren't operational

refer: https://travis-ci.org/github/pmclanahan/django-celery-email

Created Github actions workflows as replacement

• created workflow for running flake8
• created workflow for running tox
• removed flake8 from tox
• restrict workflows to run on push/pull-request to master or main branches only

TODO: remove travis update build-passing badge on readme

When sending a lot of mails with django-celery-email as backend, I often get an error in my celery logs, that there were too many concurrent connections.

I have set EMAIL_BACKEND accordingly:

EMAIL_BACKEND = 'djcelery_email.backends.CeleryEmailBackend'

And I am sending emails like so:

with mail.get_connection() as connection:
    for recipient in set(recipients):
        email = EmailMessage(subject, content, sender, [recipient],
                             headers=headers,
                             connection=connection, **kwargs)
        if attachments is not None:
            for attach in attachments:
                email.attach_file(attach)
        try:
            email.send(fail_silently=True)
        except Exception as e:
            print("Error when sending mail:", e)
            failed = True
        else:
            succeeded = True

I was expecting that this opens one connection and sends all emails using this one connection. Is this a wrong assumption? How can I force the mail backend to only use one single connection?

Hello,

I'm using 2.0.0 version on my project. I have a some problems. I found this in my log file.

"Cannot reach CELERY_EMAIL_BACKEND django.core.mail.backends.smtp.EmailBackend"

And After, we add this parameter.

CELERY_EMAIL_BACKEND = 'djcelery_email.backends.CeleryEmailBackend'

After, I have a new problem.

djcelery_email_send_multiple[49d3b5a9-b1af-424c-8709-95b506d66c49]: Failed to send email message to [u'[email protected]'], retrying. (TypeError("unsupported operand type(s) for +=: 'int' and 'list'",))

Because send_messages method of CeleryEmailBackend return to list.

https://github.com/pmclanahan/django-celery-email/blob/be1a5bb056d8acf10d33703c587c02850afd29ff/djcelery_email/tasks.py#L50

Hi,

Has anybody been able to get django-celery-email working with celery 5? I have tried to get it running but get an error and not sure of it should work out of the box or there is some compatibility issue.

Thanks

Hi @pmclanahan , Thank you for such useful library.

That PR adds support for latest actual version of Python and Django. Helpful links:

• https://docs.djangoproject.com/en/3.2/releases/3.1/
• https://docs.djangoproject.com/en/3.2/releases/3.2/