Forum OpenACS Q&A: Notifications
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?
These are all good changes. Please push them through and commit. Thanks!
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"?????
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!)
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_notificationsfor 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
notificationstable and then cleaned from the table after the hour.
This is version 0.2d of Notifications from cvs HEAD.
Is anyone else experiencing this?
A solution to the problem I was experiencing is to change line 49 in
notification::email::reply_address proc) from
I guess that the parameters to this proc shouldn't be marked as
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.