Hi Kristis,

Please find attached my new patch:
 * I have removed the unnecessary stuff (creating new Bug and User objects)
 * A new parameter changer_notification_enabled is introduced in
bugtracker's section in daemon.conf:
   1 - Changer is also notified
   0 - Changer is most likely excluded from notification as per
Bugzilla's rules.

Above is based on following observations:
By default Bugzilla excludes changer from notification when changing
bug from its web UI.
Seems not passing changer to BugMail::Send also notifies him (same as
not passing second parameter to Send at all).

If for some reason old "unsent mails" exist for a changed bug - seems
BugMail::Send for this bug sends them all.

I haven't gone deeply in activity_tag but from what I examined - seems
it adds new version in Bugzilla's product. I don't remember exactly
but I think Bugzilla doesn't send emails when adding new versions
through it's web UI. If this is the case maybe it's better to leave
notification to scmbug in this case.

Regards,
Javor

On Mon, Mar 9, 2009 at 9:58 PM, Javor Nikolov <[email protected]> wrote:
>
> Hi Kristis,
>
> I'll try to clean-up the unnecessary stuff and test if it still works.  I 
> just copy/pasted probably more than necessary from some of Bugzilla's modules 
> since I'm not familiar with it's API trying to get a quick fix of the issue.
>
> > > > +    Bugzilla::BugMail::Send( $bug->bug_id, { changer =>
> > > > $bug->reporter->login } );
> >
> >
> > Yes, why would the changer be the reporter ? In the worst case scenario
> > the changer should be the assignee, right ? That's the person that is
> > allowed to commit changes against the bug. Or, if the bug_owner policy
> > in Scmbug is not enabled, the changer is the SCM user that applies the
> > change.
>
> You're right for this. I even think the second parameter of Send is optional 
> and we don't need to override the changer - it should already be somewhere in 
> Bugzilla's database anyway.
>
>
>> Also, I wanted to ask, shouldn't we sending email notifications for all
>> activities ? Meaning, do we expect the bug-tracker to be responsible for
>> figuring out if email should be sent ? If we request email notifications
>> when a tag is applied would that be desireable ?
>
>
> IMO - any mail (or other important backend activity) which is usually 
> triggered by Bugzilla via it's web-based UI should be also performed when bug 
> is updated through scmbug. So if tag notification updates Bugzilla's bug - 
> getting mail using Bugzilla's means is desirable. Otherwise Sanity Check in 
> Bugzilla reports an error (warning) - i.e. it's kind of Bugzilla's database 
> inconsistency. I'm not sure how far is currently Bugzilla from providing a 
> decent API to just provide calls which performs the necessary change to bug 
> and notifies whoever is needed to be notified by mail or other means.
>
> In addition - not all bugtracker's users subscribed to get notified by some 
> bug's changes are also SCM users.
>
> If for some reason Bugzilla's emailing is not desirable - that should be 
> explicitly configured (preferably in Bugzilla than in scmbug but could be in 
> both) and should happen without getting Bugzilla's db inconsistent.
>
> Having ability to configure notifications from scmbug also seems a good 
> feature which should not however implicitly turnoff bugtracker's one.
>
> Regards,
> Javor

Attachment: scmbug_email_notification.patch.2
Description: Binary data

_______________________________________________
scmbug-users mailing list
[email protected]
http://lists.mkgnu.net/cgi-bin/mailman/listinfo/scmbug-users

Reply via email to