Rails core - Jul 2012 - perform_deliveries to be set per email / interceptors should he able to stop delivery

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 <https://github.com/mikel>
@josevalim<https://github.com/josevalim>
 @spastorino <https://github.com/spastorino>

-- 
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 rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

-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!

On Thu, Jul 19, 2012 at 7:37 AM, Aditya <adityavasudha@gmail.com> wrote:
> 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 <https://github.com/mikel>
@josevalim<https://github.com/josevalim>
>  @spastorino <https://github.com/spastorino>
>
> --
> 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 rubyonrails-core@googlegroups.com.
> To unsubscribe from this group, send email to
> rubyonrails-core+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/rubyonrails-core?hl=en.
>
-- 
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.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

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.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

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
http://heroku.com

@schneems (http://twitter.com/schneems)




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
(mailto:rubyonrails-core@googlegroups.com).
> To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com
(mailto:rubyonrails-core+unsubscribe@googlegroups.com).
> For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.
>  
>  

-- 
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.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

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

-- 
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.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

@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
> http://heroku.com
> @schneems <http://twitter.com/schneems>
>
> 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.
> For more options, visit this group at 
> http://groups.google.com/group/rubyonrails-core?hl=en.
>
>  
> 
-- 
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/-/5DuGKZjaaaoJ.
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.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

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

On Thursday, July 19, 2012 7:37:42 AM UTC-5, Aditya
wrote:
>
> 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 <https://github.com/mikel>
@josevalim<https://github.com/josevalim>
>  @spastorino <https://github.com/spastorino>
>
-- 
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 rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

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
http://heroku.com

@schneems (http://twitter.com/schneems)




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
> 
> On Thursday, July 19, 2012 7:37:42 AM UTC-5, Aditya wrote:
> > 
> > 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:
> > 
> > User is unsubscribed and you really want to prevent emails being sent
to such users.
> > User has a guest account with a temp internal email address, which you
do not want to send emails to.
> > 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 (https://github.com/mikel) @josevalim
(https://github.com/josevalim) @spastorino (https://github.com/spastorino)
> > 
> > 
> 
> 
> 
> -- 
> 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 rubyonrails-core@googlegroups.com
(mailto:rubyonrails-core@googlegroups.com).
> To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com
(mailto:rubyonrails-core+unsubscribe@googlegroups.com).
> For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.
-- 
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.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.