Allow to custom content type when setting mailer body #27227

Merged
merged 5 commits into from Jan 6, 2017

Projects

None yet

6 participants

@MQuy
Contributor
MQuy commented Nov 30, 2016

Summary

Allow to custom content-type in case of setting headers[:body] and attachments

attachments[:rails] = xxx
mail(
  body: "<html><body>Hello rails</body></html>",
  content_type: "text/html"
)
# => content_type is now text/hml
@sgrif sgrif was assigned by rails-bot Nov 30, 2016
@rails-bot

Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @sgrif (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

This repository is being automatically checked for code quality issues using Code Climate. You can see results for this analysis in the PR status below. Newly introduced issues should be fixed before a Pull Request is considered ready to review.

Please see the contribution instructions for more information.

@MQuy MQuy allow context type when set body mail
c4639b7
@sgrif
Member
sgrif commented Nov 30, 2016

Thank you for the pull request. Can you add documentation and a changelog entry?

@MQuy MQuy Add changelog for custom content type
2263769
@MQuy
Contributor
MQuy commented Dec 1, 2016

@sgrif thank for your feedback, I added changelog and release note.
About document, I wonder where should I add because it is just the option which we miss to check in case of attachment and header body for mailer

actionmailer/test/base_test.rb
@@ -140,6 +140,11 @@ class BaseTest < ActiveSupport::TestCase
assert_equal("multipart/mixed", email.mime_type)
end
+ test "set mime type to text/html when attachment is inclued and body is set" do
@benlovell
benlovell Dec 5, 2016

You've a typo for 'included' here.

@MQuy
MQuy Dec 5, 2016 Contributor

ty @benlovell :D

@MQuy MQuy Fix wrong typo in test
36efba0
@sgrif
Member
sgrif commented Dec 5, 2016

I would document it on the mail method

@MQuy MQuy Add document in mailer
40b1f64
@MQuy
Contributor
MQuy commented Dec 6, 2016

@sgrif thank for your feedback, I just add documentation for mail method :)

actionmailer/lib/action_mailer/base.rb
+ def collect_responses_from_text(headers)
+ [{
+ body: headers.delete(:body),
+ content_type: headers[:content_type] || self.class.default[:content_type] || "text/plain"
@MQuy
MQuy Dec 6, 2016 Contributor

@sgrif should we consider to use different name here like body_type instead of content_type, because there are some cases mailer will have many parts like mailer content_type, body content_type

@MQuy
Contributor
MQuy commented Jan 6, 2017

@sgrif i wonder is there anything lefts should i do?

actionmailer/lib/action_mailer/base.rb
+ def collect_responses_from_text(headers)
+ [{
+ body: headers.delete(:body),
+ content_type: headers[:content_type] || self.class.default[:content_type] || "text/plain"
@rafaelfranca
rafaelfranca Jan 6, 2017 Member

I think that at this point headers[:content_type] already has the value of self.class.default[:content_type].

@MQuy
MQuy Jan 6, 2017 Contributor

From what I try and debug, they are different value, because they comes from mail method and class default

@rafaelfranca
rafaelfranca Jan 6, 2017 Member

This method is only called after the apply_defaults method is called and the headers passed to this method as argument is the result of apply_defaults, so unless apply_defaults is broken. self.class.default[:content_type] should be already applied on headers[:content_type].

@MQuy
MQuy Jan 6, 2017 edited Contributor

I think apply_defaults only applies key into headers when headers doesn't have that key. In this case, we want to use the value from headers in mail method instead default from self.class.default[:content_type] 🤔

@rafaelfranca
rafaelfranca Jan 6, 2017 Member

If :content_type is passed to mail, apply_defaults will not copy the default value to the headers and headers[:content_type] will be the same as the :content_type passed to mail.

If :content_type is not passed to mail, apply_defaults will copy the default value to the headers and headers[:content_type] will be the same as the self.class.default[:content_type.

So at this point headers[:content_type] behaves exactly as we want.

@MQuy
MQuy Jan 6, 2017 edited Contributor

Really appreciate 🙇 and sorry for the late response ( just try to debug again to make sure).

Totally agree about two cases above. But the problem here is when we pass :content_type into mail method, headers[:content_type] will be different with self.class.default[:content_type]

@MQuy
MQuy Jan 6, 2017 edited Contributor

headers[:content_type] will be the same as the :content_type passed to mail

but self.class.default[:content_type] will get value from default method in actionmailer

@rafaelfranca
rafaelfranca Jan 6, 2017 Member

Is there another case different of those two?

If :content_type is passed to mail, headers[:content_type] will be the value passed to mail. In this case no matter what self.class.default[:content_type] is.

In the case you show the conditional:

headers[:content_type] || self.class.default[:content_type] || "text/plain"

will return the value of :content_type passed to mail, that is the same as headers[:content_type], unless I'm missing something.

@MQuy
MQuy Jan 6, 2017 Contributor

hum, so in this case the condition is just headers[:content_type] || "text/plain" because headers[:content_type] always contains the value of self.class.default[:content_type], right? 😄

@MQuy
MQuy Jan 6, 2017 Contributor

will refactor it, thank you so much 🙇

@MQuy MQuy Remove unnecessary condition in content_type
f091bd6
@MQuy
Contributor
MQuy commented Jan 6, 2017

@rafaelfranca thank for your suggestion 🙇, please let's me know if is there anything else need to be improved :D

@rafaelfranca rafaelfranca merged commit f091bd6 into rails:master Jan 6, 2017

2 checks passed

codeclimate no new or fixed issues
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
@maclover7 maclover7 removed the needs work label Jan 6, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment