Forum OpenACS Development: Notifications twists

Posted by Lars Pind on 02/05/03 06:12 PM

For workflow, we'll need a two twists on notifications.

1) Notify a subset.

We want to let you subscribe to notifications on all actions that you're assigned to. That's a notification type where any particular notification should only go out to a subset of the people who've requested it. So when we send out the notification, we'll pass along the list of people who are assigned to the next action in the workflow, and we want notifications to only send to those who have a request, *and* are in that list. Makes sense?

Unfortunately, the notifications package doesn't work that way. It has (a) notification types, (b) requests for notifications of that type, (c) notifications, and (d) users who already received a given notification.

That's how it knows who to send to: Everybody who requested this notification type (for this object), and who haven't yet received a notification.

How should we work around this?

One way is to reverse the data model, so instead of notification_user_map holding users already notified, it would hold users _waiting_ to be notified. I suspect the reason they didn't do this from the start was that they'd rahter have the overhead in a background thread than in the request thread that inserts the notification.

Alternatively, we could insert 'fake' rows into notification_user_map for all the users that *shouldn't* be notified this time.

Other suggestions?

2) Don't notify people twice

This is similar. The problem is that you can subscribe to the same type of event at many levels. Forums is a good example. Currently, you can subscribe to an entire forum, or a single thread.

What happens, then, when someone posts a message and you're subscribed to both forum and thread? You get notified twice!

That's not what I want. I want *one* event to result in *one* notification. Which one will be predetermined, and will typically be the most specific one first, i.e., the thread one.

This is similar, in that we want to send out notifications, but we want to limit the recipients to a subset of the ones who requested notifications.

Jeff? Don? Who else hacked on notifications or has an idea of what the best way to fix this is?

I'd assumed it worked the other way around, so I thought this was fairly trivial. Turns out it's not.

/Lars

2: Re: Notifications twists (response to 1)

Posted by Tilmann Singer on 02/07/03 02:15 PM

I didn't do that much with notifications yet, but before you get no answer at all I thought you'd better get a random-rambling-style one from me 😉

First of all, inserting fake rows seems like the wrong way to me. I don't think notifications is that mature that one should avoid data model changes for any price by doing workarounds like this.

ad 1) I had this crazy idea: what about extending notifications so that the event generating code can optionally pass a sql query string to notifications, which will be executed by notifications at the time when it builds the recipient list (i guess/hope that list is built in the background already). The query would have to return a list of user_id's only, and notifications would join it against the subscribers list so that it results in the required subset. Just an idea - maybe it's nonsense. It would at least require some thinking how to make it multi-db capable (maybe pass the name of a qd query identifier plus values for the bind vars?).

3: Re: Notifications twists (response to 1)

Posted by Carl Robert Blesius on 02/11/03 03:34 AM

There might be a problem with that 2nd twist.

I may get two notifications in forums, but these two notifications could actually be distinct (from a users perspective) as a result of varing notification intervals.

I am batched subscribed to this forum, yet after taking part in this thread I would like to be informed of new responses instantly and still receive the batched forum in its full glory.

4: Re: Notifications twists (response to 1)

Posted by Lars Pind on 02/11/03 09:48 AM

Carl,

I'm aware of this. Another example is if you're assigned to a bug in this bug-tracker, you want notification via SMS (if supported), but you also want the email, so you have it in your files.

There are basically 3 options we can choose:

- Always multiple notifications (status quo)
- Application decides between multiple or one (my solution)
- User decides

I decided against letting the user decide, because coming up with the data model and user interface to make that happen would be too large a task for our engagement.

I decided on the application-determined one-notification approach, because that's basically how the old bboard worked (if you had thread notifications, you wouldn't also get the forum notification, though I suspect you might actually still get the batch notification if you had that ...).

It's still not perfect, but I think that if we want to ensure that people get notified when they're assigned to something, we don't want them to get overloaded with spam.

What it seems is that notifications have play two different roles, only one of which was really designed into the system. One is "notify", the other is "archive".

The first is "let me know when something happens". Once you've been notified/alerted/let know, good, now you know.

The other is "I want to keep a record in my files of this". This goes somewhere where you don't read it very often, all you want is to make sure that everything gets stored away safely there.

Makes sense?

/Lars

6: Re: Notifications twists (response to 4)

Posted by Carl Robert Blesius on 02/12/03 05:22 PM

Here is what makes sense to me:

A notification is bound to an event and is made up an interval and a method.

If the method (SMS/email) or the interval (daily/instantly) varies we should get unique notifications regardless if they happen to be bound to the same event.

If the event, method, and interval are the same (regardless if the user happened to ask for both thread based and forum based notification for the same event -> a message posting) the user should only receive a single notification.

I do not want a UI for this. It would be great if the application decides (I just want the results to be intuitive).

5: Re: Notifications twists (response to 1)

Posted by Robert Locke on 02/11/03 12:53 PM

<blockquote> I decided on the application-determined one-notification
approach, because that's basically how the old bboard
worked (if you had thread notifications, you wouldn't
also get the forum notification, though I suspect you
might actually still get the batch notification if you
had that ...).
</blockquote>

Actually, I could be totally wrong, but as I recall, with the old bboard, you could decide whether or not to receive notifications for a given thread, and you actually could receive double notifications if you were subscribed to both a thread and a forum. I seem to remember this happening to me.

In the case of forums, it might make sense to provide a checkbox (or link) on a thread page which is unchecked by default when the user is subscribed to the parent forum, and checked when the user is not subscribed. The principle can be generalized from there, but the basic idea is to provide an API so that it's easy for an application to do this sort of thing. The application may have to do a bit more work, but atleast everything remains flexible.

Hope that made some sense...

7: Re: Notifications twists (response to 1)

Posted by Lars Pind on 02/13/03 05:59 PM

Carl,

I think that's a great solution. I'll go ahead and implement that.

/Lars