Thanks for looking into this!

On 25 April 2011 16:22, Gary Poster <email address hidden> wrote:
[...]
>  - Since your report and now, perhaps we've fixed the problem
> incidentally.  Do you still get the unexpected emails?

Yes. I've got an example later for you.

>
>  - As you know, subscriptions are unioned to determine what
> notifications you receive.  It may well be that you have additional
> subscriptions to Launchpad that you didn't expect.  I think you can
> check this (even though you are not currently in the group to get all
> features) if you go to
> https://bugs.launchpad.net/launchpad/+subscriptions.  When I go to that
> page, I see that I am subscribed via a Launchpad Bug Contacts
> subscription to *all* changes.  I bet you are too.

That page and launchpad-project/+subscriptions are both empty... which
is a little puzzling because I do have a structural subscription with
a filter on launchpad-project:

  Bug mail for Gavin Panella about Launchpad Suite is filtered; it
  will be sent only if it matches the following filter:

    “Triage” allows mail through when:
    the status is New or Incomplete

I have an example for you, an email I received earlier today:

  Subject: [Bug 771335] [NEW] Title of add subscription widget ...

  If the bug target name is long the title of the subscription
  add/edit form can wrap.  Se attached screen shot for example.

  ** Affects: launchpad
      Importance: High
          Status: Triaged

  --
  You received this bug notification because you are subscribed to
  Launchpad Suite.
  Matching subscriptions: Triage
  https://bugs.launchpad.net/bugs/771335

Note the "Matching subscriptions" line and the status. The activity
log for that bug also shows that the status was set at the time the
bug was filed (i.e. in +filebug), not after.

[...]
> On launchpad.dev:
>
> 1) For convenience, verify that you get the new features.  Go to
> https://launchpad.dev/+feature-rules and make sure that these rules, or
> something like them, are in place.  Note that <email address hidden>:test
> has the necessary privileges to do this, probably among other sampledata
> users.
>
> malone.advanced-structural-subscriptions.enabled        default 1       yes
> malone.advanced-subscriptions.enabled   default 1       yes
>
> 2) Set up a project that has the subscriptions set up as you describe.
> I set up the firefox project to work as you described, and verified via
> the +subscriptions page of the bug I was going to modify
> (https://bugs.launchpad.dev/firefox/+bug/1/+subscriptions) that
> everything was as I expected.  Note that this bug matches the "Triage"
> filter initially.
>
> 3) I ran "cronscripts/send-bug-notifications.py -vv" to clear out
> pending notifications.
>
> 4) I added a comment on bug 1 that I expected to receive as a
> notification, as a control.
>
> 5) I changed the status of bug 1 to be Confirmed.  It now no longer
> matched the filter.
>
> 6) I added another comment that I hoped to not receive, because it did
> not match the filter.

The problem manifests with bugs that have their status set at
bug-filing time, in +filebug, rather than with existing bugs. If you
repeat these steps but report a new bug against firefox, setting the
status to Triaged within the Extra options expander, you should get a
different outcome.

>
> 7) I waited 3-5 minutes for the notification code to be willing to send
> the mail (well, actually, first I ran send-bug-notifications.py, and
> when I didn't get any emails at all I remembered I had to wait).
>
> 8) I ran "cronscripts/send-bug-notifications.py -vv" again and examined
> the output.  foo.bar would have received the first notification, but not
> the second.  The new header and body text I described above about the
> filter name was there.  It looked good.

These steps look good otherwise.