Activity stream

[olivierdalang]

Initial implementation of activity stream using django-notifications.

I'm not 100% this is the best choice.
There's also django-activity-stream, which looks includes feature to follow/unfollow, but lacks seen/unseen.
There's also pinax-notifications, which looks like it it also takes care of the actual sending of the emails (the other ones don't do that)

But it is installed in a separate activity app, it should be relatively independent and not too hard to change afterwards. We also probably would need to sort out proper emailing solution on production as otherwise we'll very likely end up having all our sent emails flagged as spam.

Currently, it logs user creation, organization creation, membership addition/removal. But I didn't really think of what notification actually make sense. Can we list those ? (esp. for stuff linked to deltas/conflicts/etc).

[olivierdalang]

Had some strange failures happening from tearDown methods of tests, when it deletes all created objects.

Not exactly sure why it failed though...

But anyways, the deletion in tearDown should not be needed, as Django's TestCase are ran in transactions that are rolled back, so I just removed that code.

[suricactus]

Is it possible to have this a configuration like notifs_frequency_m = models.UIntField(min=0, choices=IntChoices)? This way it would be easier to change the configuration for the users.

[olivierdalang]

Currently there's just four different django_crons set up (SendNotificationsJobImmediately, SendNotificationsJobHourly, SendNotificationsJobDaily, SendNotificationsJobWeekly).
If we wanted this to be customizable, we'd run every minute for everybody, but would then need to store last execution time for each user.

Not sure it's worth going down that rabbit hole ?

[suricactus]

hm, isn't it enough to have a sent_at field in the Notification model? Whenever the cron runs, you call:

notifs = Notification.objects.filter(user=user, sent_at__isnull=True)
send_notif_emails(notifs)

Or you mean that we don't have sent_at field at all?

[olivierdalang]

The issue is that if we wanted to make it easy to customize the frequency using an integer (minutes) rather than predefined choices, we'd also need some kind of scheduling strategy.

Currently it uses 4 different crons, on for each frequency, so we have predefined/hard-coded available schedules only.

It's not impossible to make it customizable, but then we'd need to store when the cron was last sending emails run for every user as they'd all run on the same minutely cron. IMO not really worth the complexity.

We could add more predefine frequencies if you think it's needed, but I think with immediate (minute), hourly, daily and weekly we've got most need covered ?

[olivierdalang]

Ok as per discussion implemented this (hehe not sure why this was overcomplex in my head ?). Used a DurationField instead of int field so it simplifies date arithmetic functions

[olivierdalang]

Did you check the changes under docker-app/qfieldcloud/core/tests/test_* ? Not sure why these were required, but here test used to fail without those.

Do you want me to squash this in a more detailed way (differentiating strictly notification based stuff from the rest) ?

Also we've got branching migrations (42, merged in 46), should I linearize that ?

[suricactus]

Let me know when you think we are ready for a final review and merge.

[olivierdalang]

ok cleaned up commit history (to isolate unrelated changes), ready for final review/merge