[ckan-dev] RFC: Activity streams on-site and email notifications

[Sean Hammond]

> >For the on-site notification, we need to add the concept of "seen" and
> >"unseen" activities to the model on a per-user basis. My idea is to add
> >a datetime column to the user table which records the last time they saw
> >their activity stream, and count any activities newer than that as
> >unseen.
> 
> One issue here might be that users have different activity streams
> to look at. So it would be rather nice to know which activity stream
> I have looked at since when.

Hi Sven, I can see what you're getting at here, but I think we only want
to track unseen activities for the user's dashboard activity stream,
i.e. the private activity stream that she controls the contents of by
following and unfollowing things, and not for all the other public
activity streams on the site.

> >For the email notification the plan is to add an "unsent notifications"
> >table to the database and add a notifier job that runs periodically and
> >consumes rows from this table, sending them as emails (this is from an
> >older spec for the same feature).
> 
> As I wrote in the issue sheet, this might cause problems because
> everywhere in CKAN notifications can be spawned which is in fact NO
> advantage. I remember a project from which in fact this behavior has
> been removed because nobody writing a particular feature wanted to
> bother about how to send emails. Furthermore, nobody actually knew
> anymore where all message were coming from.
> So, I would go for a more centralized approach (which can be
> modularized anyway) that collects the required data from db and
> created messages from time to time and that can remind remind users
> when they have unseen activities.

Personally I like the idea of a single unsent notifications queue and a
logic action function for adding something to the queue. Yes the action
function could then be called from many places in CKAN (other action
functions, controllers, templates or template helper functions,
extensions, by a user via the action API...), but I don't think it
should be too difficult to track where notifications are coming from
because they all have to go through this logic action function, so you
just look for calls to this function. (And to be honest, this is true of
other logic action functions in CKAN as well, such as spawning
activities that appear in activity streams.)

If we have a centralised approach that somehow infers notifications from
data in the db, then code throughout CKAN code "unintentionally" spawn
notifications by making some innocent db change that then triggers the
notifier to infer a notification from it. Here I think it might really
become difficult to track which lines of code throughout CKAN are
triggering notifications. So I like the idea of having to explicitly call a
logic action function to create a notification.