Opened 7 years ago

Closed 5 years ago

#7722 closed (fixed)

EMail Message with CC - Carbon CopyFixed patch

Reported by: roberto.digirolamo <robydigi91@…> Owned by: nobody
Component: Core (Mail) Version: master
Severity: Keywords:
Cc: robydigi91@…, django@…, richard.davies@…, dougvanhorn@…, tom@…, alex-sort.django@… Triage Stage: Ready for checkin
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:


I modified class EmailMessage for use Carbon copy.

    def __init__(self, subject='', body='', from_email=None, to=None, cc=None, bcc=None,
            connection=None, attachments=None, headers=None):
        Initialize a single email message (which can be sent to multiple

        All strings used to create the message can be unicode strings (or UTF-8
        bytestrings). The SafeMIMEText class will handle any necessary encoding
        if to:
   = list(to)
   = []
        if cc: = list(cc)
		else: = []
        if bcc:
            self.bcc = list(bcc)
            self.bcc = []
        self.from_email = from_email or settings.DEFAULT_FROM_EMAIL
        self.subject = subject
        self.body = body
        self.attachments = attachments or []
        self.extra_headers = headers or {}
        self.connection = connection

	def message(self):
		encoding = self.encoding or settings.DEFAULT_CHARSET
		msg = SafeMIMEText(smart_str(self.body, settings.DEFAULT_CHARSET), self.content_subtype, encoding)
		if self.attachments:
			body_msg = msg
			msg = SafeMIMEMultipart(_subtype=self.multipart_subtype)
			if self.body:
			for attachment in self.attachments:
				if isinstance(attachment, MIMEBase):
		msg['Subject'] = self.subject
		msg['From'] = self.from_email
		msg['To'] = ', '.join(
		if not == None:
			msg['Cc'] = ', '.join(
		msg['Date'] = formatdate()
		msg['Message-ID'] = make_msgid()
		for name, value in self.extra_headers.items():
			msg[name] = value
		return msg

	def recipients(self):
		Returns a list of all recipients of the email (includes direct
		addressees as well as Bcc and Cc entries).
		return + + self.bcc

Best regards,

Attachments (3)

mail.diff (1.5 KB) - added by roberto.digirolamo <robydigi91@…> 7 years ago.
mail_fixed.diff (1.6 KB) - added by EAndre 7 years ago.
cc-r13609.diff (4.8 KB) - added by dougvanhorn 5 years ago.
Patch updated against r13609, includes modest regression and doc changes.

Download all attachments as: .zip

Change History (23)

comment:1 Changed 7 years ago by roberto.digirolamo <robydigi91@…>

  • Cc robydigi91@… added

comment:2 Changed 7 years ago by garcia_marc

  • Has patch unset
  • Triage Stage changed from Unreviewed to Design decision needed

You should add the patch as a result of svn diff, to let us know where the changes are (then attach it as a file).

comment:3 Changed 7 years ago by garcia_marc

  • milestone set to post-1.0

Changed 7 years ago by roberto.digirolamo <robydigi91@…>

comment:4 Changed 7 years ago by berto

I second this change; just had to patch CC in too.

comment:5 Changed 7 years ago by chr

  • Cc django@… added

comment:6 Changed 7 years ago by Richard Davies <richard.davies@…>

  • Cc richard.davies@… added

comment:7 Changed 7 years ago by EAndre

  • Has patch set
  • Needs documentation set
  • Needs tests set
  • Patch needs improvement unset

Attaching a new patch; the previous patch had some funkiness with regards to indentation (it used tabs), and a missing space in the doctext of EmailMessage.recipients().

Leaving this as Design decision needed, since the argument order is changed and is therefore a [slightly] backwards incompatible change.

Changed 7 years ago by EAndre

comment:8 Changed 7 years ago by mtredinnick

  • milestone post-1.0 deleted

Backwards compatibility is very simple in cases like this: you must not change the argument order. It simply isn't an option.

I'm still pretty much -0 or -1 on this feature, since it's unnecessary for functionality purposes and you can subclass the class if you really, really want it for some reason. I'll leave it open for now, though, in case another maintainer falls in love with the idea (or similarly dislikes it, in which case we can close it off).

comment:9 Changed 6 years ago by dougvanhorn

This has already been closed once in #5790.

I'm actually +1 for adding CC support, as it seems a bit counter-intuitive to support BCC but not CC. As a user of the API, when I see the fields 'from', 'to', and 'bcc', I pretty much expect to see CC. Having to subclass (or worse, cut and paste) an object called EmailMessage to support CC just doesn't seem right.

If I understand the reasoning why it was originally refused, it was because EmailMessage is not intended to be a full featured email API. Which seems odd, as attachments and MIME alternatives are supported, which are certainly at least as complex to support as CC.

In regards to CC not adding any functionality not already supported by the API, that may be true. However, CC's are semantically important to business users, and they are typically the people who pay us to build their systems with Django.

Since patching is pretty simple, and adds a very common and logical field to the object, is there a desire to not pollute the arglist in the EmailMessage constructor?

comment:10 Changed 6 years ago by dougvanhorn

  • Cc dougvanhorn@… added

comment:11 Changed 6 years ago by Richard Davies <richard.davies@…>

How about adding the CC to the end of the argument list, rather than in the middle?

Not where we would put it starting from scratch, but would add the functionality, and would maintain backward compatibility, which Malcolm was concerned about...

comment:12 Changed 6 years ago by gert

Call me old fashioned, but to me it seem silly to provide core email functionality which handles HTML, attachments and even BCC but then tell the developers that they have to subclass and make their own if they want to CC.

Surely that does not sound like a framework for perfectionists with deadlines?

I am willing to bet my lunch that anyone reading this at least once a day writes or receives an email in which someone is CCed, this is basic functionality (much more so than HTML or attachments) and need to be implemented in the core.

PS: As previously suggested, add CC to the end of the parameter list if backward compatibility needs to be maintained, but please add it.

comment:13 Changed 6 years ago by Thomas Steinacher <tom@…>

  • Cc tom@… added


comment:14 Changed 6 years ago by dannyman@…

Gert speaks for me, and I think he speaks for many others.

+1 here!


comment:15 Changed 5 years ago by adehnert

  • Cc alex-sort.django@… added

I'd like to see this feature. It looks like nobody's spoken against this feature in almost two years. Is this still something that people are opposed to?

Thanks, Alex.

comment:16 Changed 5 years ago by shacker

I'll add my voice to the chorus -- big time +1 from me.

cc: is standard/basic fare in any mail-capable software, not something we should have to bend over backwards to implement in our systems. And it's fine if the argument is at the end of the list. It just needs to be there.

comment:17 Changed 5 years ago by russellm

  • Patch needs improvement set
  • Triage Stage changed from Design decision needed to Accepted

Ok - I'll accept this one. It really is a bit silly that we don't support CC, given that we support all the other email fields.

The patch needs to be updated to trunk, and we need docs and tests before it will get into trunk.

Changed 5 years ago by dougvanhorn

Patch updated against r13609, includes modest regression and doc changes.

comment:18 Changed 5 years ago by dougvanhorn

  • Summary changed from EMail Message with CC - Carbon Copy to EMail Message with CC - Carbon CopyFixed patch

I added a new patch coded against r13609. I'm not sure about the regression testing and modifying existing ones, so I added a few new tests at the bottom.

Also, I didn't want to throw cc into the middle of the arglist as the docs specifically talk about positional arguments, so it's at the end of the EmailMessage and EmailMultiAlternatives constructors.

Last, I modified the docs, adding 'cc' to the list of arguments.

I suppose if the cc arg ends up in a different position something will need to be added to the list of "backwards incompatible" changes.

comment:19 Changed 5 years ago by SmileyChris

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Accepted to Ready for checkin

Good changes, doug.

I modified the docs very slightly:

comment:20 Changed 5 years ago by lukeplant

  • Resolution set to fixed
  • Status changed from new to closed

Fixed in [14000], thanks.

Note: See TracTickets for help on using tickets.
Back to Top