In my rails 4.2.5 (ruby 2.2.1) app I have an actionmailer class that is so simple. It doesn't even send mail, just does a printf:
class UserTommail < ActionMailer::Base
def joe
printf("\n***** In Emails.joe")
end
end
But when my controller calls this function, it never does the printf!
def contact_us
printf("\n***** TOMS EMAILLER")
UserTommail.joe()
redirect_to(root_path(), :notice => "Your Contact Us message has been successfully sent.")
printf("\n**** TOMS END")
end
The two printfs in the controller actually print their message, but the one in joe() never does. No errors or anything.
If I sabotage joe() to say joe() in the file user_tommail.rb, I get an error that the function can't be found, so I know the controller knows about it.
What am I doing wrong?
You should call deliver_now to fire the mailer to send the email:
UserTommail.joe.deliver_now
See the full list of available methods in docs.
For Rails 4 to send a an email
UserTommail.joe.deliver_now
or
UserTommail.joe.deliver_later #Enqueues the email to be delivered through Active Job. When the job runs it will send the email using deliver_now.
For Rails 3 to send a an email
UserTommail.joe.deliver
The problem here is that ActionMailer tries to be "clever" about what it does, and won't actually call your mailer method until its return value is needed.
Your mailer method joe will return an ActionMailer::MessageDelivery object, which wraps a Mail::Message object (even though you haven't specifically said you want to send an email). The Mail::Message gets lazily evaluated, meaning it won't be instantiated (and your method won't be called) until it's needed.
One way of forcing the evaluation would be to try and send the returned email with deliver_now or deliver_later, but another way would simply be to inspect the message.
if you had my_email = UserTommail.joe() and then called my_email.message, it would force the method to be run and you would see your printf in the console.
Related
We're currently letting users email each other without seeing each other's actual email addresses (double blind) by letting them send emails to username#parse.example.com which works great.
class ForwardsMailbox < ApplicationMailbox
before_processing :ensure_users
def process
content = mail.multipart? ? mail.parts.first.body.decoded : mail.decoded
UserMailer.with(sender: sender, recipient: recipient, subject: mail.subject, content: content).forward_email.deliver_later
end
private
def sender
#sender ||= User.find_by(email: mail.from.first)
end
def recipient
#recipient ||= User.find_by(username: mail.to.first.split('#').first)
end
def ensure_users
bounce_with UserMailer.invalid_user(inbound_email) if sender.nil? or recipient.nil?
end
end
Is it possible to forward the whole mail object instead of extracting its contents, checking if it is multipart etc?
Try to give this a shot. Reuse the mail object in your process method and directly deliver the message yourself. You'll need to reach into ActionMailer to get your delivery methods configured correctly, but I believe it'll work.
def process
mail.to = sender.email
mail.from = recipient...
ActionMailer::Base.wrap_delivery_behavior(mail) # this sets delivery to use what we specified in our rails config.
mail.deliver # This delivers our email to the smtp server / API
end
How this works:
Behind the scenes Mailers are just calling deliver on a Mail object to send emails. You can go peruse through ActionMailer::MessageDelivery if you'd like to see that in action. We're just using that functionality directly here.
I'd recommend staying away from using Mailers in this instance because copying over all the fields from your original mail object to the mailer's mail object is going to require a lot of trial and error.
One thing to note: the headers remain unchanged when the message is re-delivered, so things like Message-ID will still be the same (which may or may not be a problem, just something to consider).
Last, if you're concerned at all about deliver being a blocking call to an API/SMTP server like I was, worry not! It looks like ActionMailbox already ensures that the process method runs via ActiveJob, so you shouldn't have to worry about an SMTP/API request taking a while and blocking a web request (see ActionMailbox guides).
I have an RSpec test like this:
it "should ..." do
# mailer = mock
# mailer.should_receive(:deliver)
Mailer.should_receive(:notification_to_sender)#.and_return(mailer)
visit transactions_path
expect do
page.should_not have_css("table#transactions_list tbody tr")
find('#some_button').click
page.should have_css("table#transactions_list tbody tr", :count => 1)
end.to change{Transaction.count}.by(1)
end
If I remove the commented pieces at the top, the test passes. But with the commented sections in place (how I'd expect to write it) the test fails.
I got the commented pieces off some of googling around the net, but I don't really understand what it's doing or why this fixes it. It seems like there should be a cleaner way to test emails without this.
Can anyone shed some light? Thanks!
I'm using rails 3 and rspec-rails 2.10.1
I think you want an instance of Mailer to receive notification_to_sender not the class. From the Rails API
You never instantiate your mailer class. Rather, your delivery instance methods are automatically wrapped in class methods that start with the word deliver_ followed by the name of the mailer method that you would like to deliver. The signup_notification method defined above is delivered by invoking Notifier.deliver_signup_notification.
Therefore I would use
Mailer.any_instance.should_receive(:notification_to_sender)
Also, if you need to get the last delivered message, use
ActionMailer::Base.deliveries.last
I think that should solve your problem.
You're likely calling Mailer.notification_to_sender.deliver in your controller, or better yet, a background job. I'm guessing notification_to_sender probably takes a parameter as well.
Anyways, when you call the notification_to_sender method on Mailer you're getting back an instance of Mail::Message that has the deliver method on it. If you were simply doing Mailer.notification_to_sender without also calling deliver, you could run what you have there with the comments and all would be fine. I would guess you're also calling deliver though.
In that case your failure message would be something like
NoMethodError:
undefined method `deliver' for nil:NilClass
That is because nil is Ruby's default return value much of the time, which Rails also inherits. Without specifying the mailer = mock and .and_return(mailer) parts, when the controller executes in context of the test then notification_to_sender will return nil and the controller will try to call deliver on that nil object.
The solution you have commented out is to mock out notification_to_sender's return value (normally Mail::Message) and then expect that deliver method to be called on it.
I am newbie in Rails, therefore sorry for silly question. For sending emails I use ActionMailer with Rails 2.3.5. The syntax is following
deliver_maintest1
deliver_maintest2
in model of instance of ActionMailer I have
def maintest1
end
def maintest2
end
Inside definitions I set recipient, subject, headers,...As I understand there is no any explicity defined method mail which is actually sent email. Emails are sent from def maintest1 and maintest2. The problem is before sending email I need to define few counters how many emails were sent thought maintest1 and maintest2. Now take into account I have tens defs like maintest. So I need a common place for all those defs. In your opinion what's the best solution?
Thanks!
On rails 3 and above you could use an observer. These get called after every mail delivery, passing through the message object. You just need to implement a delivered_email class method and register it.
class EmailObserver
def self.delivered_email(message)
# do something with message
end
end
Then, hook it into mail with
Mail.register_observer(EmailObserver)
This doesn't work on rails 2.x, which doesn't use the mail gem (it uses tmail from the ruby standard library.)
On 2.3.x I would try something like
class MyMailer < ActionMailer::Base
def deliver!(mail=#mail)
super
# do your logging here
end
end
You would be calling "Mailer.deliver_maintest" to send the mails out to anyone, to count the nos of times you sent a particular email you just need to keep track of it each time you call "Mailer.deliver_maintest" .
You can store that counter either the database or somewhere. something like this.
// Some lines of code to Update the counter for the mailer
Mailer.deliver_maintest
You can also use a third party email tool like PostMark to send your email ( with them you can associate each email with tags, and I just generally use those tags to keep track of emails sent out ).
The output from an email sent from ActionMailer output to the log, I wanted to know if I could get that output into a variable so I can store it in a file.
Ps. I forgot to mention that this is on Rails 2
As McStretch has pointed out, observer is the best way to handle every message that is delivered by a mailer. However, if you'd like to just capture 1 or 2 special cases, you can do the following:
Assuming you have an ActionMailer subclass called MyMailer, and an email called foobar,
# Rails 2.x
mail = MyMailer.create_foobar(...) # instead of MyMailer.deliver_foobar(...)
File.open('filename.txt', 'wb') {|f| f.write(mail.body) }
MyMailer.deliver(mail)
# Rails 3.x
mail = MyMailer.foobar(...) # instead of MyMailer.foobar(...).deliver
File.open('filename.txt', 'wb') {|f| f.write(mail.body) }
mail.deliver
You can use the register_interceptor or register_observer methods on ActionMailer to do something before or after sending the mail, respectively. The ActionMailer docs state:
Action Mailer provides hooks into the
Mail observer and interceptor methods.
These allow you to register objects
that are called during the mail
delivery life cycle.
An observer object must implement the
:delivered_email(message) method which
will be called once for every email
sent after the email has been sent.
An interceptor object must implement
the :delivering_email(message) method
which will be called before the email
is sent, allowing you to make
modifications to the email before it
hits the delivery agents. Your object
should make and needed modifications
directly to the passed in
Mail::Message instance.
Each of these methods provide a Mail::Message as an argument, so you should be able to get the desired data from that object and save it somewhere:
class MyInterceptor
def self.delivering_email(mail)
# do something before sending the email
end
end
class MyObserver
def self.delivered_email(mail)
# do something after sending the email
end
end
Example above from http://blog.envylabs.com/2010/04/new-in-rails3-beta2/
According to the Rails API (snippet below), the optimal way to receive mail is by creating a single Rails instance within a daemon that gets invoked by a MTA whenever new mail arrives.
My question is: how do you pass data to that daemon when new mail arrives?
========================
Rails API Snippet
To receive emails, you need to implement a public instance method called receive that takes a tmail object as its single parameter. The Action Mailer framework has a corresponding class method, which is also called receive, that accepts a raw, unprocessed email as a string, which it then turns into the tmail object and calls the receive instance method.
Example:
class Mailman < ActionMailer::Base
def receive(email)
page = Page.find_by_address(email.to.first)
page.emails.create(
:subject => email.subject, :body => email.body
)
if email.has_attachments?
for attachment in email.attachments
page.attachments.create({
:file => attachment, :description => email.subject
})
end
end
end
end
This Mailman can be the target for Postfix or other MTAs. In Rails, you would use the runner in the trivial case like this:
./script/runner 'Mailman.receive(STDIN.read)'
However, invoking Rails in the runner for each mail to be received is very resource intensive. A single instance of Rails should be run within a daemon if it is going to be utilized to process more than just a limited number of email.
In the example you provide, there is no daemon running to process email. The documentation is saying you can setup your mailer daemon, Postfix in this case, to invoke a command when mail is received. When you call the command from your mailer:
RAILS_ROOT/script/runner 'Mailman.receive(STDIN.read)'
The content of the email is passed into the receive method. A much better way to handle processing incoming email is to create an actual mailbox that receives email. You can then write a Ruby script that batch checks the mailbox to process the email. You can call that script via cron with lock run around it to insure that there is only one process performing this task.