Send mail using repoze.sendmail for Invite New User

[Paul Everitt]

Summary
===========

Convert the IMailer dummy implementation to a repoze.sendmail queue that is drained by a console script.

Background
============

KARL3 has a bunch of communities (projects). You an add existing KARL3 users to your community. You can also invite a new user to join your community and thus KARL3. Both of these user stories result in sending an email to the person.

The Invite New User screen/view can be reached by:

- Go to http://localhost:6543/communities/default

- Most likely, get redirected to login then redirected back

- Click in the "Members" link above the green Edit box, taking you to Go to http://localhost:6543/communities/default/members

- Click the "Invite New" action in the green actions box.

- Put your email on a line in the text area, type in a short message, then click submit.

Coding
============

Here are some starter points on knowing your way around the code:

- The view that implements this is in karl.views.members.invite_new_user_view

- This line sends the mail:

  mailer.send(info['mfrom'], to_email, message, info['subject'])

- The IMailer utility is implemented in karl.utilities.mailer

- ISettings provides the mail server location. It is controlled using the standard BFG ISettings concept, which means the knob is in etc/osi.ini.

Tasks
=========

- Re-implement the Mailer class to use repoze.sendmail and a queue

- Make sure the console script in bin correctly drains the queue and reports any errors

- Consider moving the ILogger out of the views and into the Mailer.send method

- Make sure the logger is wired up appropriately

- Document (and email Paul) how the script runs that drains the queue, any configuration, etc.

[Paul Everitt (paul-agendaless)]

My guess is that this is around 6 hours, mostly because it is your first foray into KARL3. Feel free to ask questions.

This is assigned to M2, which is targeted for end of tomorrow (Thursday.) I'm acting as if you have around 8 hours in the next 2 days available. If that is incorrect, let me know.

[Chris Rossi (chris-archimedeanco)]

Hi Paul,

Friday or Monday is more realistic for me in terms of getting some hours in
for Karl. I have other client obligations today and tomorrow and a sales
meeting Friday morning. I'm also moving this weekend!

Can M2 be pushed back or does this ticket need to be reassigned? I'm fairly
confident I could deliver by Tuesday.

Thanks,
Chris

On Wed, Feb 18, 2009 at 9:47 AM, Paul Everitt <email address hidden> wrote:

> My guess is that this is around 6 hours, mostly because it is your first
> foray into KARL3. Feel free to ask questions.
>
> This is assigned to M2, which is targeted for end of tomorrow
> (Thursday.) I'm acting as if you have around 8 hours in the next 2 days
> available. If that is incorrect, let me know.
>
> ** Changed in: karl3
> Importance: Undecided => Medium
> Assignee: (unassigned) => Chris Rossi (chris-archimedeanco)
> Target: None => m2
>
> --
> Send mail using repoze.sendmail for Invite New User
> https://bugs.launchpad.net/bugs/331042
> You received this bug notification because you are a member of KARL3
> Developers, which is the registrant for KARL3.
>
> Status in Porting KARL to a new architecture: New
>
> Bug description:
>
> Summary
> ===========
>
> Convert the IMailer dummy implementation to a repoze.sendmail queue that is
> drained by a console script.
>
> Background
> ============
>
> KARL3 has a bunch of communities (projects). You an add existing KARL3
> users to your community. You can also invite a new user to join your
> community and thus KARL3. Both of these user stories result in sending an
> email to the person.
>
> The Invite New User screen/view can be reached by:
>
> - Go to http://localhost:6543/communities/default
>
> - Most likely, get redirected to login then redirected back
>
> - Click in the "Members" link above the green Edit box, taking you to Go to
> http://localhost:6543/communities/default/members
>
> - Click the "Invite New" action in the green actions box.
>
> - Put your email on a line in the text area, type in a short message, then
> click submit.
>
> Coding
> ============
>
> Here are some starter points on knowing your way around the code:
>
> - The view that implements this is in
> karl.views.members.invite_new_user_view
>
> - This line sends the mail:
>
> mailer.send(info['mfrom'], to_email, message, info['subject'])
>
> - The IMailer utility is implemented in karl.utilities.mailer
>
> - ISettings provides the mail server location. It is controlled using the
> standard BFG ISettings concept, which means the knob is in etc/osi.ini.
>
> Tasks
> =========
>
> - Re-implement the Mailer class to use repoze.sendmail and a queue
>
> - Make sure the console script in bin correctly drains the queue and
> reports any errors
>
> - Consider moving the ILogger out of the views and into the Mailer.send
> method
>
> - Make sure the logger is wired up appropriately
>
> - Document (and email Paul) how the script runs that drains the queue, any
> configuration, etc.
>

[Paul Everitt (paul-agendaless)]

Moving out of M2. ChrisR will let me know on Monday how much availability he has next week.

[Chris Rossi (chris-archimedeanco)]

Will use a development egg for repoze.sendmail until I learn how to release packages in repoze. I suspect the configuration story for the mailer will need some figuring out.

[Chris Rossi (chris-archimedeanco)]

Done. Replaced karl.interfaces.IMailer with repoze.sendmail.interfaces.IMailDelivery. Registered QueuedMailDelivery implementation as a utility. When "send" method is called, mail is added to queue in a maildir on filesystem. Default location is "var/mail_queue" and can be overridden in "etc/osi.ini". Queue can be drained by "bin/qp var/mail_queue". Leave off args to see all command line options.

[Paul Everitt (paul-agendaless)]

I just gave it a try and it worked the first time!

Couple of questions:

1) Can we get a command line flag for qp that puts it in verbose mode?
It is a bit scary to run it and see nothing happen. [wink]

2) Related to that...what is the story for integration with Python
logging, which is our story for logging?

3) Can you explain how daemon mode works? Is it as simple as it sounds?
  And, does daemon have a story related to logging?

--Paul

Chris Rossi wrote:
> Done. Replaced karl.interfaces.IMailer with
> repoze.sendmail.interfaces.IMailDelivery. Registered QueuedMailDelivery
> implementation as a utility. When "send" method is called, mail is
> added to queue in a maildir on filesystem. Default location is
> "var/mail_queue" and can be overridden in "etc/osi.ini". Queue can be
> drained by "bin/qp var/mail_queue". Leave off args to see all command
> line options.
>
>
> ** Changed in: karl3
> Status: In Progress => Fix Committed
>

[Chris Rossi (chris-archimedeanco)]

On Tue, Feb 24, 2009 at 8:25 PM, Paul Everitt <email address hidden> wrote:

>
> 1) Can we get a command line flag for qp that puts it in verbose mode?
> It is a bit scary to run it and see nothing happen. [wink]
>

Sure.

>
> 2) Related to that...what is the story for integration with Python
> logging, which is our story for logging?
>

It uses Python logging. The logger name is "QueueProcessor" if you wind up
manipulating it from Python code. Smtp errors are logged. There is also
one call to log.info to verify sending of a message but it looks like the
output is extraordinarily minimal: "Mail from %s to %s sent." I can
probably make that more informative. The zope.sendmail author has a comment
in there about adding message id. We could even go crazy and log the whole
message, I suppose. Disk is cheap, right? When the queue processor is run
as a console script, there is only a call to logging.basicConfig(), so I
think that means errors and warnings are sent to standard error and that's
about it. I can, of course, add options to kick up the verbosity (ie
include info level messages) and route the output to a file somewhere.

> 3) Can you explain how daemon mode works? Is it as simple as it sounds?
> And, does daemon have a story related to logging?
>

Daemon mode is a fancy name for infintite loop. It polls the queue, sends
emails, sleeps for interval seconds and then does it all over again. There
is not currently an init.d style start/stop/etc style command for
manipulating the process, although I suppose there could be. The logging
story for daemon mode is the same as the logging story for non-daemon (hit
it and quit?) mode. The couple of tweaks mentioned above would probably get
you what you want in terms of logging. I also found it helpful during
testing to monitor the log of my smtp daemon.

Chris