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

[Sven R. Kunze]

Hi everybody,

On Mon, 22 Oct 2012 16:29:03 +0200, Sean Hammond <sean.hammond at okfn.org>  
wrote:

> 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.

I suggested a tracking table that tracks on which page the user was at  
which time, so that from that on-site notifications can be inferred.

However, Sean already outlined that users might mark on-site notifications  
as 'seen' via different means (API, website, ...), so that an additional  
column could identify the way of having notifications seen.

My concern here is that we reinvent the wheel, because URLs are there to  
identify where a user have been and actually seen something when we go for  
different bubbles (on-site notifications) for different activity streams.
These tracking data can be used also for other purposes such as statistics.

When we go for just one bubble indicating everything -- which indeed I  
find too less -- than the approach Sean's mentioned should suffice.


> 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.


Regards.