Forum OpenACS Q&A: Notifications

Collapse
1: Notifications
Posted by Lars Pind on 08/01/02 12:32 PM
I'm looking at using forums and notifications, and thus I'm checking
it out a bit. So far I've run into a couple minor issues:

notificaions/www/request-new.tcl: The form id is "request", which
happens to be a reserved form id in the form builder (ugh!). The
consequence is that the form-builder thinks that the form is always
in submission-mode, causing the annoying "Email is required" form
error. Solution: Simply change the form id to "subscribe" in
both .tcl and .adp files.

Next problem is that the request-new page doesn't include any
header, context bar, etc. In dotLRN, there's a gigantic header, so
this doesn't look too stupid, but in the default installation, it
does look dumb with no header at all. Should we add the usual
headers? How about the context bar?

The page also accepts a pretty_name parameter. Unfortunately, this
isn't supplied by the notification::display::subscribe proc, so the
title of the page remains "New Notification Request for " .. for
nothing. Fortunately, this is pretty simple to add, since
notification::display::request_widget already require a pretty_name
parameter. Should I add that?

/Lars

Collapse
2: Response to Notifications (response to 1)
Posted by Ben Adida on 08/01/02 03:48 PM
Lars,

These are all good changes. Please push them through and commit. Thanks!

Collapse
3: Response to Notifications (response to 1)
Posted by Lars Pind on 08/01/02 04:26 PM
Done.
Collapse
4: Response to Notifications (response to 1)
Posted by Don Baccus on 08/01/02 07:39 PM
Next problem is that the request-new page doesn't include any header, context bar, etc. In dotLRN, there's a gigantic header, so this doesn't look too stupid, but in the default installation, it does look dumb with no header at all. Should we add the usual headers? How about the context bar?
Yeah, it should as Ben says but this reminds me that these elements should be kicked upstairs towards the master template rather than explicitly put out by package template pages. The presentation (or even suppression of presentation) of these elements should be something one can whack in the site master template. A 4.6 item ...

Also a minor nitpick but one I feel fairly strongly about ... notifications uses "-url" when it means "-return_url", which means you have to actually read the code to understand what the param is meant to be (nor is the param documented in standard style ...). PLEASE can we maintain conventions like the naming of "return_url"?????

Collapse
5: Response to Notifications (response to 1)
Posted by Lars Pind on 08/02/02 01:20 AM
Re context bars and 4.6: Yes, absolutely. But (as you know) this is going to take a major tree-wide sweep (one of many, presumably).

/Lars

Collapse
6: Response to Notifications (response to 1)
Posted by Don Baccus on 08/02/02 01:40 AM
Yes, you're right, a tree-wide sweep will be necessary.

Since you gained so much experience doing tree-wide sweeps to clean up template hierarchies for Greenpeace I sorta figured you'd just pop up and volunteer to do the job! :)

(ouch, quit hitting me, you insensitive Dane with no sense of humor!)

Collapse
7: Response to Notifications (response to 1)
Posted by Stephen . on 08/02/02 01:41 AM
Not necessarily, it could be done package by package.  Pages within a package would have their furniture drawn by a package specific master template.  When the default-master is eventually updated to draw nav bars etc. then only the package masters have to be modified.  It would be handy to be able to modify style on a package by package basis anyway.
Collapse
8: Response to Notifications (response to 1)
Posted by Lars Pind on 08/02/02 07:25 AM
:)
Collapse
9: Response to Notifications (response to 1)
Posted by Bjorn Thor Jonsson on 08/24/02 04:46 PM
Is there a known problem with batching notifications in the Notifications package?

In a test setup I have Forums installed and one user with one request of hourly notifications from one thread.

If I post a few messages to this thread and then run the test.tcl file of the notifications package (runs notification::sweep::sweep_notifications for all intervals), I receive all messages in individual e-mails, rather than batched up in one.

If I post a few messages to the same thread and then wait the hour, no e-mails are received, though I see the messages being added to the notifications table and then cleaned from the table after the hour.

This is version 0.2d of Notifications from cvs HEAD.

Is anyone else experiencing this?
Collapse
10: Response to Notifications (response to 1)
Posted by Bjorn Thor Jonsson on 08/25/02 04:01 PM

A solution to the problem I was experiencing is to change line 49 in notification-email-procs.tcl (the notification::email::reply_address proc) from
return [reply_address_prefix]
to
return "[reply_address_prefix]@[address_domain]"

I guess that the parameters to this proc shouldn't be marked as :required either.

Should I submit a formal bug report for this, or is this post enough? Where is the best place for bug reports for Notifications? I don't see it defined as a module in the OpenACS SDM or as a component in the dotLRN Bug Tracker.