EMail Message with CC - Carbon CopyFixed patch

[roberto.digirolamo <robydigi91@…>]

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
        recipients).

        All strings used to create the message can be unicode strings (or UTF-8
        bytestrings). The SafeMIMEText class will handle any necessary encoding
        conversions.
        """
        if to:
            self.to = list(to)
        else:
            self.to = []
        if cc:
			self.cc = list(cc)
		else:
			self.cc = []
        if bcc:
            self.bcc = list(bcc)
        else:
            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:
				msg.attach(body_msg)
			for attachment in self.attachments:
				if isinstance(attachment, MIMEBase):
					msg.attach(attachment)
				else:
					msg.attach(self._create_attachment(*attachment))
		msg['Subject'] = self.subject
		msg['From'] = self.from_email
		msg['To'] = ', '.join(self.to)
		if not self.cc == None:
			msg['Cc'] = ', '.join(self.cc)
		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.to + self.cc + self.bcc

Best regards,
Roberto

[Marc Garcia]

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).

[berto]

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

[EAndre]

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.

[Malcolm Tredinnick]

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).

[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?

[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...

[Gert Steyn]

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.

[Thomas Steinacher <tom@…>]

+1

[dannyman@…]

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

+1 here!

Thanks,
-danny

[adehnert]

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.

[Scot Hacker]

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.

[Russell Keith-Magee]

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.

[dougvanhorn]

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

[dougvanhorn]

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.

[Chris Beaven]

Good changes, doug.

I modified the docs very slightly: ​http://github.com/SmileyChris/django/compare/master...7722-email-cc

[Luke Plant]

Fixed in [14000], thanks.