[newmaint-site] Notification on process progress using signals

[Enrico Zini]

On Fri, Aug 30, 2013 at 11:19:30PM +0200, Marco Bardelli wrote:

> so I thought mail sending has to be triggered by a detached thread on
> 'post_save' Process, to ensure that the database is coherent with
> notifications.

Sounds good. A big try/except around maybe_notify_applicant_on_process
is probably a good idea, so that we get a log entry if an email hasn't
been sent out for some unexpected reason.

> In order to compose emails by using the django template system,
> I saved the templates under /templates/notification_mails, but
> we can surely choose a better place.

Good place. I like the idea of having all the email templates in one
place.

> Concerning the email templates I wrote, that are obviously to be
> corrected, I am a bit confused on this example:
> https://lists.debian.org/debian-newmaint/2009/04/msg00026.html
> because in the db there are no AM consideratons (P&P,T&S) that are
> instead present in the announcement example.
> This could be maybe solved by using a particular Log stored in the db.

Don't worry, we can simply drop all those sections (ID check, P&P, T&S)
that don't fit with the new database model.

> Attached, you will also find a README.md correction for south and markdown.

Ok. I pushed the README.md fixes to master.

I also pushed a new 'emails' branch with your patch and my changes.

I've worked on two of the templates:

 - public_am_approved_applicant.txt: removed all info we don't currently
   have
 - am_assigned_to_applicant.txt: merged with what was sent by
   nm_am_match in restricted/views.py

I've documented each template with a comment listing the expected
context values.

In restricted/views.py there is still the advocate_as_dd view that sends
an email; that one is triggered by proc.advocates.add(request.person)
instead of a status change. Since it doesn't fit with the current
detection strategy during signals, we can just leave it there in the
view. It may make sense to refactor it to use an external template,
though.

There is an issue in that request.person is not available in signals, so
we can't know who did the change (for example, to sign the email saying
'I've assigned you a new AM'.

An alternative strategy could be to trigger on signals posted when a new
log entry is entered. Comparing the current and previous log entry we
can know both the status change that happened, the process involved and
the person who did the change.

Random other notes:

 - there could be a single context provided for all templates, so we
   only need to document what ends up in email templates once.
 - we currently don't do word wrapping of email bodies, and templates
   cannot decide From, To and Subject of emails.
 - we miss a public comment from the AM. We could use the log entry
   provided during AM approval for it, after making it very clear in the
   status change interface that the message is going to be public.
   Alternatively, we can provide a dedicated 'am approval' view with
   textareas for private and public comments.

I think your patch is a good starting point for an interesting little
refactoring of the site.

This evening we can have a little brainstorming about it IRL.


Ciao,

Enrico

-- 
GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini <enrico at enricozini.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/newmaint-site/attachments/20130902/42632f66/attachment.sig>