Django 1.11 fires the save signals in more cases than 1.8 did it seems,
so we can generate extra notifications for example when the twitter
script posts a news item to twitter.
To avoid this, just don't send notification if the user is unknown
(=None).
Per discussion with Jonathan
If the m2m field is optional, there will be no "pre" data available, not
even an empty one. Don't crash in this case, just assume it's empty
(which it is).
This could happen when adding a new Organisation, which currently is the
only model we have with optional m2m fields
Unfortunately, we'll send one email for each m2m field, instead of
collecting them to a single one. That's because there is no signal
delivered at the end of them all, there will be one sent for each field.
Luckily we don't have a lot of m2m fields at this point, and no model
has more than one, so at this point that part is not a problem.
It also means that if a regular field *and* an m2m field is changed,
then we will get two notifications.
Finally, enable these notifications for the Organisation fields, meaning
we will get a notification when an Organisation changes managers, which
was not working before.
Instead of reporting the integer value of the foreign key, we should
report the text value from the related object. This makes the new
submissions more readable, and also makes the system not throw an
exception when trying to diff (as integers cannot be diffed).
THis seems to have broken around the time of the 1.8 upgrade, just went
unnoticed for a long time probably because changing things like which
organization owns a news item doesn't happen very often.
Previous code triggered a conversion from unicode to ascii inside the
django framework, which would throw an exception when the object itself
returned unicode in the name.
The new version will work around that by actually checking the primary
key first.
This still doesn't work insofar that any changes to a many2many fields
are now lost. This did not work properly before either, but this
probably made it a bit work. We definitely need to fix this properly at
some point, probably by using the m2m_changed signal handler (but it's
not straight forward as this is now a separate signal and we'll somehow
want to track this indepdendently)
We were already using signals for everything except delete, and even
in our old version of django the delete signal exists (it didn't exist
when this code was first written).
Django doesn't really like models to be OOP like this, so keeping PgModel
would cause issues with upcoming changes in django 1.8. Using simple functions
is easier, and the actual functionality is replicated straight off.
