perform_deliveries to be set per email / interceptors should he able to stop delivery

214 views
Skip to first unread message

Aditya

unread,
Jul 19, 2012, 8:37:42 AM7/19/12
to rubyonra...@googlegroups.com

It would be nice to have mail interceptor be able to modify the message to prevent delivery. Alternatively it would be nice to also prevent delivery in the mailer itself.

The use cases are as follows:

  1. User is unsubscribed and you really want to prevent emails being sent to such users.
  2. User has a guest account with a temp internal email address, which you do not want to send emails to.
  3. The email content may be spammy and you want to prevent that delivery.

As such you could do each by wrapping more code around the MyMailer.mail_action(args)/.deliver pattern but it gets repetitive quickly.

This is not environment specific which is already handled very well in Rails since ages, this is more transactional. If we can already do this easily, feel free to point me to the right direction. Happy to send patch in due time if this is acceptable.

Possible routes i'm thinking are to add options to mail itself (:perform_delivery => determine_delivery(args)) and/or adding ability to prevent delivery from interceptor.

Suggestions/Ideas?

/cc @mikel @josevalim @spastorino

Andrés Mejía

unread,
Jul 19, 2012, 11:31:45 AM7/19/12
to rubyonra...@googlegroups.com
-1.

I don't see the point of this option. If you don't want to send an email, then don't call the mailer method and that's it.

Also:

3. The email content may be spammy and you want to prevent that delivery

Well, don't spam your users in the first place!

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group.
To view this discussion on the web visit https://groups.google.com/d/msg/rubyonrails-core/-/Xq3K3q2q4QIJ.
To post to this group, send email to rubyonra...@googlegroups.com.
To unsubscribe from this group, send email to rubyonrails-co...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.

Thibaut Barrère

unread,
Jul 19, 2012, 11:43:39 AM7/19/12
to rubyonra...@googlegroups.com
Hi,

I met the same need (eg: to avoid sending any email until the user is
"confirmed" for instance) but did not implement anything yet.

I would probably just create a custom_mail method to be used in place
of mail, which would decide based on your logic if mail must be called
or not.

That said having a "global" hook to stop delivery could be useful too.

Just a thought!

-- Thibaut

Richard Schneeman

unread,
Jul 19, 2012, 12:08:33 PM7/19/12
to rubyonra...@googlegroups.com
Having the ability to easily comply to CAN-spam and other email legislation without having to add an if clause to _everywhere_ you are sending out email would be nice. 

Looks like you can already do something like this a mail interceptor: http://stackoverflow.com/questions/8594626/how-to-add-a-before-filter-in-usermailer-which-checks-if-it-is-ok-to-mail-a-user, though the OP never responded whether that works or not. 



-- 
Richard Schneeman
--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group.

Thibaut Barrère

unread,
Jul 19, 2012, 12:15:39 PM7/19/12
to rubyonra...@googlegroups.com
If an interceptor can cleanly stop the delivery even for say Devise or
other dependencies initiated emails, it would provide a consistent
behaviour through the apps, which would be neat.

-- Thibaut

Aditya

unread,
Jul 20, 2012, 8:26:06 AM7/20/12
to rubyonra...@googlegroups.com
@schneems Thanks!

Seems you cant prevent deliveries from interceptor as yet. I understand that checking on the user model before delivering is always going to be hard/unclean from interceptor (how is the interceptor going to get hold of the user model anyway?) but preventing deliveries from interceptors shouldnt be.

I still havent thought how I can cleanly prevent all deliveries to some users use case but at the very least I could flag them in each mailer action where the mail is being sent. Another way I'm thinking this could be prevented is to override the "email" reader in the user model and return an address that could help the interceptor prevent delivery.


On Thursday, 19 July 2012 21:38:33 UTC+5:30, richard schneeman wrote:
Having the ability to easily comply to CAN-spam and other email legislation without having to add an if clause to _everywhere_ you are sending out email would be nice. 

Looks like you can already do something like this a mail interceptor: http://stackoverflow.com/questions/8594626/how-to-add-a-before-filter-in-usermailer-which-checks-if-it-is-ok-to-mail-a-user, though the OP never responded whether that works or not. 



-- 
Richard Schneeman

On Thursday, July 19, 2012 at 10:43 AM, Thibaut Barrère wrote:

Hi,

I met the same need (eg: to avoid sending any email until the user is
"confirmed" for instance) but did not implement anything yet.

I would probably just create a custom_mail method to be used in place
of mail, which would decide based on your logic if mail must be called
or not.

That said having a "global" hook to stop delivery could be useful too.

Just a thought!

-- Thibaut

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com.

Richard Schneeman

unread,
Jul 20, 2012, 3:49:10 PM7/20/12
to rubyonra...@googlegroups.com
This conversation is diverting from the original. 

The question was whether a patch for this functionality would be useful, I personally would find it useful. And on that front we're done. 

If you want to talk about alternate implementations using existing Rails functionality please move the conversation over to Rails-Talk list. If you have questions or need advice cc/ me in a pull request. 

-- 
Richard Schneeman

On Friday, July 20, 2012 at 8:57 AM, Matthew Johnston wrote:

Try looking into a state machine. When the user confirms, then send an email. It's really easy to think about

(guest) -- #confirm --> (confirming) -- #finished --> (active)

before_transition :on => :confirm, :do => :send_confirmation_email

Then do some magic on the confirmation side that triggers the #finished event.

Hope this helps

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group.
To view this discussion on the web visit https://groups.google.com/d/msg/rubyonrails-core/-/lxnPH9Phqn4J.
To post to this group, send email to rubyonra...@googlegroups.com.
To unsubscribe from this group, send email to rubyonrails-co...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages