launchpad-dev team mailing list archive

[Abel Deuring <abel.deuring@xxxxxxxxxxxxx>]

Hi Robert, hi Stuart,

I started to work on
https://dev.launchpad.net/LEP/BetterBugSubscriptionsAndNotifications .
The basic idea is to allow filtering of emails from bug subscriptions by
the same search crietria which we already use here:
https://bugs.edge.launchpad.net/malone/+bugs?advanced=1

Users could for example click a button "subscribe to this search" on web
pages that show bug search results; notifications for any bugs matching
the given search would be sent to the subscriber.

I could come up with two implementation ideas, but I don't like both of
them very much...

(1) Add a table SubscriptionFilter with columns like bugtask_status,
bugtask_importance, bugtask_assignee, bugtask_reporter, milestone etc;
bug notifications would be sent if all non-null values of a
SubscriptionFilter row match those of the given bug[task]. The main
problem this approach: To represent a subscription like "all valid open
bugs with importance High or Critical for milestones A or B" we would
need 12 rows for all combinations of the status values Confirmed,
Triaged, In Progress, two importance values and two milestone values...
An alternative is to use several tables, like SubscriptionFilterStatus,
SubscriptionFilterImportance etc. Another problem: If the filter
specifies a full text search, we have the interesting query "give me all
rows which define a full text search that matches the current bug".

(2) Just store some representation of the search parameters, for example
the query part of the regular search URL, in a text column of a table
SubscriptionFilter. If a subscription is associated with a filter, we
call BugTaskSet.search() with the filter parameters and we pass
additionally the ID of the "current" bug; if the the result set is not
empty, the bug notification mail is sent. So, one or more SQL queries
for each "filtered subscription", but since we have a WHERE clause like
"bug.id=N", it should be quite fast. Also, we can be fairly sure that
subscribers receive mails about exactly those bugs they would see on a
search results page. (A crazy variant would be to squeeze
BugTaskSet.search() into a stored procedure so that we can call it
directly in the query "find all subscriptions for the current bug
notification"...)

I currently tend to use variant 2, but variant 1 could perhaps be
improved, and there might be completely different approaches.

Abel