This includes a number of new features:
* Move some moderation functionality into shared places, so we don't
keep re-inventing the wheel.
* Implement three-state moderation, where the submitter can edit their
item and then explicitly say "i'm done, please moderate this now".
This is currently only implemented for News, but done in a reusable
way.
* Move moderation workflow to it's own set of URLs instead of
overloading it on the general admin interface. Admin interface remains
for editing things, but these are now separated out into separate
things.
* Do proper stylesheet clearing for moderation of markdown fields, using
a dynamic sandboxed iframe, so it's not ruined by the /admin/ css.
* Move moderation email notification into dedicated moderation code,
thereby simplifying the admin subclassing we did which was in some
places quite fragile.
* Reset date of news postings to the date of their approval, when
approved. This avoids some annoying ordering issues.
Most of our auto-generated emails should not ask for auto replies (like
out of office messages or in particular, "held for moderation" notices
from our own list server), so set this header by default, and also the
header indicating if it's an auto submitted/auto replied message.
Specifically allow auto replies on moderation notices, since that's a
case where it might be really interesting for the moderator to see for
example an out of office message. At least for now that seems like a
good idea.
This broke when we had ManyToMany relations on a record. We didn't use
to have that, but with tags for news we now do. With this change, the
"reject with a notice" becomes a two step operation, the first one
adding the notification and the second one doing the removal. That'll
have to do for now, and at some point in the future we may create a
completely separate (non /admin/) workflow for moderation and fix it
that way.
Import the code from the PostgreSQL Europe website to handle this, since it's
well proven by now.
Any points that send email now just write them to the database using the
functions in queuedmail.util. This means we can now submit notification
emails and such things within transactions and have them properly roll bcak
if something goes wrong (so no more incorrect notifications when there is
a database error).
These emails are picked up by a cronjob that runs frequently (typically
once per minute or once every 2 minutes) that submits them to the local
mailserver. By doing it out of line, this gives us a much better way of
dealing with cases where mail delivery is really slow.
The submission from the cronjob is now done with smtp to localhost instead
of opening a pipe to the sendmail command - though this should have no
major effects on anything.
This also removes the setting SUPPRESS_NOTIFICATIONS, as no notifications
are actually ever sent unless the cronjob is run. On development systems
they will just go into the queuedmail table, and can be deleted from there.
Must be the same as in in the inherited-from class, or we ended up
passing a python dict as a string, and render the contents of it as
the "action" attribute on the form.
This should fix the problem where notifications weren't sent for objects
being deleted through the "mass deletion" function in the list of objects.
Closes#121
Notices entered will be sent to the organisations email address - so there
needs to be one (if not, the notification field doesn't show up).
Notifications also go in the database, and show up on each object so you
can see the previous history of it, and get emailed to the slaves list.
Finally, it's possible to reject-with-notification, in which case the
notification is sent off to the user and after that the object is deleted.
The notification history stays in the database, but is not linked anywhere
(but can be viewed from the admin interface on that model directly).
Unfortunately, this seems to cause double notifications to the slaves list,
but we'll have to live with that for now.
Closes#137
