432976 - Email assignees when their bugs are still open and the deadline is over

Status: NEW

(Bugzilla :: Whining, enhancement, P2)

Description

[Pascal Engler]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; W-XP; .NET CLR 2.0.50727; .NET CLR 1.1.4322)
Build Identifier: 3.0.3

If you enter a deadline in a bug, it would be very nice if the bug owner gets an e-mail when you reach a day after your entered deadline.

Otherwise you have to filter which bugs are over the deadline.

Reproducible: Always

Steps to Reproduce:
Just enter a deadline.

Comment 1

[Frédéric Buclin]

You can already build a query which returns bugs which passed the deadline and which are still open. What you cannot do is to email the bug owner (aka assignee) about them.

editwhines.cgi should accept addressees such as %assignee%, %reporter% and %qa_contact%, as we have for queries themselves already. This way, we could address emails to the appropriate persons more easily. Of course, the usage of %foo% should require bz_canusewhineatothers privs.

Note that rather emailing assignees when the deadline is behind, it would make more sense to email the before the deadline. This feature would come alongside the existing whineatnews.pl script.

Comment 2

[Max Kanat-Alexander]

Yeah, I think this would be a reasonable feature to add, even separate from whining. It can use Whining as the backend, but it'd be nice to just have a simple checkbox for it, for the admin to set up or possibly as a User Preference.

Comment 3

[Pascal Engler]

Yeah that would be great if there is just a checkbox for the admin.

So I'm looking forward to the bugzilla version with this checkbox.

Comment 4

[rojanu]

Attachment: Whining at deadline

Comment 5

[Frédéric Buclin]

Comment on attachment 499277 [details] [diff] [review]
Whining at deadline

>+    whine($query, "email/whineatdeadline.txt.tmpl");


This template is missing in the patch.

Comment 6

[rojanu]

Attachment: Whining at deadline

Forgot to include whineatdeadline.txt.tmpl into the patch

Comment 7

[Frédéric Buclin]

Very quickly:

- The license in the new template is wrong, see
  http://www.mozilla.org/MPL/boilerplate-1.1/mpl-sh

- The author of the new template is you. If your template is very close to the existing one, then maybe an [% IF %] [% ELSE %] [% END %] block in that template would make sense, to avoid duplicating code.

- Lines are way too long. Limit them to 80 characters.

- Your URL won't work if the assignee is not in the timetracking group. All bugs will be returned.

- This notification will be confusing to users who cannot see timetracking fields. I wonder if the assignee of a bug shouldn't automatically see timetracking fields, or at least the deadline field (just thinking loud, unrelated to this bug).

Comment 8

[Marc Schumann [:Wurblzap]]

Alternatively, this could be a standard whine Bugzilla ships with. Having a separate entity for this seems redundant to me.

Comment 9

[rojanu]

Attachment: Whining at deadline

Shortened lines, corrected license, using one email template instead of two and updated deadline query URL

Comment 10

[Max Kanat-Alexander]

(In reply to comment #8)
> Alternatively, this could be a standard whine Bugzilla ships with. Having a
> separate entity for this seems redundant to me.

  That sounds pretty sensible to me. I think I would prefer that.

Comment 11

[rojanu]

(In reply to comment #8)
> Alternatively, this could be a standard whine Bugzilla ships with. Having a
> separate entity for this seems redundant to me.

I am not sure if I understood what exactly you mean

(In reply to comment #7)
> - This notification will be confusing to users who cannot see timetracking
> fields. I wonder if the assignee of a bug shouldn't automatically see
> timetracking fields, or at least the deadline field (just thinking loud,
> unrelated to this bug).
LpSolit: Where are we with "Should the assignee see the deadline independently of his privs?"

Comment 12

[Marc Schumann [:Wurblzap]]

I mean that I can use the existing whine system to have Bugzilla email assignees when their bugs are still open and the deadline is over. I don't see why we need a separate param, template and code.

My suggestion is to have checksetup.pl create such a whine (with its saved search and an "everybody" group) when installing a new Bugzilla.

Comment 13

[rojanu]

Attachment: Deadline whine schedule

OK,  I have created this patch and only thing that puzzled me is who the default user should be?

Comment 14

[Max Kanat-Alexander]

Comment on attachment 515618 [details] [diff] [review]
Deadline whine schedule

  Thanks for this patch! :-)

  Okay, this may require some small code modifications to Bugzilla itself.

  Create a parameter called "whine_on_passed_deadlines" that the administrator can set to on or off. I'll comment on this patch and explain why:

>=== modified file 'Bugzilla/Install/DB.pm'
>+    my $userid = 1;

  Ah, you can't just safely pick that userid.

>+    my ($event_id) = $dbh->selectrow_array("SELECT id FROM whine_events ".
>+                                             "WHERE ".
>+                                             "subject = 'Bugs passed deadline'");

  Putting an English string like that into the database makes it impossible to localize.

>+        $dbh->bz_start_transaction;

  Nit: Needs () before ;.

>+        my $everybodyGroup = 'Deadline_Group';

 We don't need to create a new group, we can use whatever the timetrackinggroup is currently. However, this changes over time, so I think that this will have to be a "special" whine sent by whine.pl if the parameter that I described above is on.

>+        $sth->execute($userid,'Bugs_Passed_Deadline','bug_status=CONFIRMED&
>+                                          bug_status=IN_PROGRESS&
>+                                          bug_status=RESOLVED&

  Ah, you should just have "resolution=---" -- that catches all open bugs. Closed bugs are closed and thus not past the deadline.

>+                                          field0-0-0=deadline&
>+                                          type0-0-0=lesdbhaneq&

  Should be "lessthaneq" (looks like there's just a typo).

>+                                          value0-0-0=-1d&

  You don't need the - in front of 1d. Actually, you can use 0d here, which means "the beginning of today".

>+                                          field0-1-0=assigned_to&
>+                                          type0-1-0=equals&
>+                                          value0-1-0=%25user%25&

  Running this once per user is probably not going to perform well on installations that have 200,000 users. Instead when we implement this as a custom part of whine.pl, we should just do this search once, leave out this term, and then just send to the assignees.

>+                                          order=bug_id');

  Perhaps we should order by deadline in reverse?

>+                                          
>+        my ($named_query_id) = $dbh->selectrow_array("SELECT id FROM namedqueries ".
>+                                                 "WHERE ".
>+                                                 "name = 'Bugs_Passed_Deadline'");

  So if we do that, we won't need to put anything into the namedqueries table.

>+        $sth->execute($userid,'Bugs passed deadline','Following bugs passed their deadline',0);

  I suppose that all of these strings will have to be in templates instead, in template/en/default/global/messages.html.tmpl instead. Then you can get them inside of whine.pl using the "get_text" function from Bugzilla::Util.


  Anyhow, I want to be clear that I really appreciate all your work on this. I think that just seeing it now, though, has made me realize that we will need some small bit of custom code--that custom code should just be built on top of the existing Whining system.

Comment 15

[Marc Schumann [:Wurblzap]]

(In reply to comment #14)
> >+    my ($event_id) = $dbh->selectrow_array("SELECT id FROM whine_events ".
> >+                                             "WHERE ".
> >+                                             "subject = 'Bugs passed deadline'");
> 
>   Putting an English string like that into the database makes it impossible to
> localize.

This is not the problem. The problem is that the subject is not dependent on the user's language. But that's a different bug. So for me as a localizer, it doesn't matter here in this bug.

What does matter, though, is that if somebody changes the subject (to e.g. "Overdue" or you name it), the next checksetup.pl run will create another same query.

Comment 16

[rojanu]

(In reply to comment #14)
>   Ah, you can't just safely pick that userid.
I am aware of that but none of the users can safely picked!!!
Can we just not use user?

>   Putting an English string like that into the database makes it impossible to
> localize.

> >+                                          
> >+        my ($named_query_id) = $dbh->selectrow_array("SELECT id FROM namedqueries ".
> >+                                                 "WHERE ".
> >+                                                 "name = 'Bugs_Passed_Deadline'");
> 
>   So if we do that, we won't need to put anything into the namedqueries table.
> 
> >+        $sth->execute($userid,'Bugs passed deadline','Following bugs passed their deadline',0);
> 
>   I suppose that all of these strings will have to be in templates instead, in
> template/en/default/global/messages.html.tmpl instead. Then you can get them
> inside of whine.pl using the "get_text" function from Bugzilla::Util.

I suppose above two are the same, but even by putting messages into template Wurblzaps concern still stands

> 
> >+        my $everybodyGroup = 'Deadline_Group';
> 
>  We don't need to create a new group, we can use whatever the timetrackinggroup
> is currently. However, this changes over time, so I think that this will have
> to be a "special" whine sent by whine.pl if the parameter that I described
> above is on.

what do you mean by "special whine", is it code change in whine.pl to bypass group.

> 
>   Running this once per user is probably not going to perform well on
> installations that have 200,000 users. Instead when we implement this as a
> custom part of whine.pl, we should just do this search once, leave out this
> term, and then just send to the assignees.
I am not sure I understood!

Comment 17

[Marc Schumann [:Wurblzap]]

Max,
a "special whine" is exactly what we want to avoid, isn't it? It'd be redundant. Seeing that it isn't necessary, I don't like the idea of modifying whine.pl for this. We wouldn't want to add special whines for every good whining idea, either. And on top, it'd be nice to have a useful and working whining example shipping with Bugzilla.

Performance issues shouldn't worry too much for a nightly query, either.

Comment 18

[Frédéric Buclin]

Why having a parameter for that? Just create the whine. If the admin doesn't run whine.pl, he is not concerned. If the admin doesn't want it, he can simply delete it.

You still didn't answer my last point of comment 7.

Comment 19

[Max Kanat-Alexander]

(In reply to comment #18)
> I am aware of that but none of the users can safely picked!!!
> Can we just not use user?

  You would have to create this whine at the time of creating the initial admin, which is in Bugzilla::Install.

> I suppose above two are the same, but even by putting messages into template
> Wurblzaps concern still stands

  No, Wurblzap's concern can be dealt with very easily if the strings are in templates. In fact, whine.pl already deals with it!

> what do you mean by "special whine", is it code change in whine.pl to bypass
> group.

  I mean that we would not add this whine to the database at all, but we would accomplish it via special code in whine.pl.

> I am not sure I understood!

  I misunderstood your code. :-) However, there is still a problem: the summary of this bug suggests something useful--"email assignees when their bugs are still open and the deadline is over". Your patch does something different--it notifies a particular group of users about every single bug in Bugzilla whose deadline has passed. Emailing me about just the bugs that are passed their deadline would be useful to me. Emailing me about every single bug in bugzilla.mozilla.org that is past its deadline would not be useful to me.

  So we need some way to only email the assignees of the bugs about this, and only if they are in the timetrackinggroup, for now (no matter what the timetrackinggroup happens to be at the moment).

Comment 20

[Marc Schumann [:Wurblzap]]

(In reply to comment #19)
> > I suppose above two are the same, but even by putting messages into template
> > Wurblzaps concern still stands
> 
>   No, Wurblzap's concern can be dealt with very easily if the strings are in
> templates. In fact, whine.pl already deals with it!

No, renaming the whine will break the concept.

> > what do you mean by "special whine", is it code change in whine.pl to bypass
> > group.
> 
>   I mean that we would not add this whine to the database at all, but we would
> accomplish it via special code in whine.pl.

Because of the redundancy, that's not the right way.

Comment 21

[Max Kanat-Alexander]

(In reply to comment #20)
> No, renaming the whine will break the concept.

  Oh, no, there wouldn't be a named Whine. There would just be the parameter.

> Because of the redundancy, that's not the right way.

  Mmm, I disagree that it would be redundant--there is a good way to implement this with minimal redundancy. :-)

Comment 22

[Marc Schumann [:Wurblzap]]

There *should be* a named whine.

Current whining can do the job. Everything else is most definitely redundant.

Comment 23

[Max Kanat-Alexander]

(In reply to comment #22)
> Current whining can do the job. Everything else is most definitely redundant.

  Hmm, how do you write a single Whine that runs once a day that emails every assignee when their deadlined bugs are past the deadline? How do you make the subject and content localizable for each recipient?

Comment 24

[Max Kanat-Alexander]

(In reply to comment #23)
>   Hmm, how do you write a single Whine that runs once a day that emails every
> assignee when their deadlined bugs are past the deadline? How do you make the
> subject and content localizable for each recipient?

  Also, how do you restrict this Whine to being received only by members of the timetrackinggroup, no matter what that parameter happens to currently be set to?

Comment 25

[Marc Schumann [:Wurblzap]]

(In reply to comment #23)
>   Hmm, how do you write a single Whine that runs once a day that emails every
> assignee when their deadlined bugs are past the deadline?

I don't. See comment 17.

> How do you make the subject and content localizable for each recipient?

I don't. That's a bug in whining. It doesn't need to be fixed here.

>   Also, how do you restrict this Whine to being received only by members of the
> timetrackinggroup, no matter what that parameter happens to currently be set
> to?

I don't. It doesn't need to behave this way. I simply set up an example whine which works sensibly and whines at everybody. If somebody wants to modify this, he's free to do so -- using the existing whining admin gui.
Also, see Frédéric's comment 7: it'd be a good idea to make the deadline field not part of the timetrackinggroup restriction.

Comment 26

[Marc Schumann [:Wurblzap]]

Comment on attachment 515618 [details] [diff] [review]
Deadline whine schedule

>=== modified file 'Bugzilla/Install/DB.pm'
>--- Bugzilla/Install/DB.pm	2011-02-11 18:41:02 +0000
>+++ Bugzilla/Install/DB.pm	2011-02-28 15:07:30 +0000
>+    my ($event_id) = $dbh->selectrow_array("SELECT id FROM whine_events ".
>+                                             "WHERE ".
>+                                             "subject = 'Bugs passed deadline'");
>+    if (!$event_id) {
>+        print "Adding Bugs deadline...";

Maybe it'd suffice to look for *any* whine, and set up the deadline whine if there isn't any whine at all in Bugzilla yet?
Existing installations wouldn't get the whine automatically, but that's not really a problem because it can be set up easily manually.

Comment 27

[Max Kanat-Alexander]

> I simply set up an example whine which works sensibly and whines at everybody.

  Ah, okay. Yeah, I wouldn't accept that as the default behavior of Bugzilla. It wouldn't scale well and in most situations that I've worked in, it would just be annoying to get a lot of notifications about other peoples' bugs. No reason to ship a system that is annoying by default.

> Also, see Frédéric's comment 7: it'd be a good idea to make the deadline field
> not part of the timetrackinggroup restriction.

  I agree, so if we do that first, we won't have to worry about the timetrackinggroup restriction, here.

Comment 28

[Marc Schumann [:Wurblzap]]

(In reply to comment #27)
> > I simply set up an example whine which works sensibly and whines at everybody.
> 
>   Ah, okay. Yeah, I wouldn't accept that as the default behavior of Bugzilla.
> It wouldn't scale well and in most situations that I've worked in, it would
> just be annoying to get a lot of notifications about other peoples' bugs. No
> reason to ship a system that is annoying by default.

I'm sorry, I seem not to have been clear. Scaling isn't much of a worry for a nightly whine, in any big installation there are other scheduled queries which are as big.

And no, you wouldn't be notified about other peoples' bugs. Why would it be that way? The searches has assigned_to-equals-%user% in it.

Comment 29

[Max Kanat-Alexander]

(In reply to comment #28)
> I'm sorry, I seem not to have been clear. Scaling isn't much of a worry for a
> nightly whine, in any big installation there are other scheduled queries which
> are as big.

  Okay. Are you proposing one whine owned by one person, or one whine per user?

> And no, you wouldn't be notified about other peoples' bugs. Why would it be
> that way? The searches has assigned_to-equals-%user% in it.

  That would require one whine per user. %user% is just the currently-logged-in user. Note that there are over 200,000 users in bmo's database, as an example. Running 200,000 queries is not really feasible.

Comment 30

[Marc Schumann [:Wurblzap]]

(In reply to comment #29)
>   Okay. Are you proposing one whine owned by one person, or one whine per user?

One whine owned by one person.

> > And no, you wouldn't be notified about other peoples' bugs. Why would it be
> > that way? The searches has assigned_to-equals-%user% in it.
> 
>   That would require one whine per user. %user% is just the currently-logged-in
> user. Note that there are over 200,000 users in bmo's database, as an example.
> Running 200,000 queries is not really feasible.

No, it wouldn't require one whine per user; whine.pl is clever enough. (It'd require one db query per user on each whine run, though, maybe that's what you mean.)

If running 200,000 queries in a nightly run really isn't feasible, then the admin can use the existing whining admin gui to point the whine to some other group. ("active_developers", say.)

If you really want a special whine for this, then give me special whines for
 o bugs nearing the due date (n days in advance), notifying assignee
 o bugs where the qa contact hasn't set the status to VERIFIED or CONFIRMED
   n days after the bug has been RESOLVED, notifying qa contact
 o same as previous, but bugs without qa contact, notifying reporter
 o bugs which sit idle for n days, notifying assignee
 o whatever comes into somebody's mind next
too.

Comment 31

[Max Kanat-Alexander]

(In reply to comment #30)
> No, it wouldn't require one whine per user; whine.pl is clever enough. (It'd
> require one db query per user on each whine run, though, maybe that's what you
> mean.)

  Ah, that's right, I had forgotten that.

> If you really want a special whine for this, then give me special whines for
> [snip]

  I was actually thinking of creating a whole framework for special whines as a part of this.

  Also, all of those suggestions are actually really good. Perhaps some of this could be an extension.

Comment 32

[rojanu]

Attachment: Special Whines

OK,  I had look at the whine.pl and schedule time is stored in the database and it has to be store somewhere for all jobs to know when to execute.

I created a specialwhine.pl file to replace the whineatnews.pl and to include a hook to add new jobs.  The skeleton idea is there and wanted to get an approval of the idea before I spent time on any further work needed.

Comment 33

[Frédéric Buclin]

(In reply to Marc Schumann [:Wurblzap] from comment #12)
> I mean that I can use the existing whine system to have Bugzilla email
> assignees when their bugs are still open and the deadline is over.

That's not exactly true. It's true that we have bug 283609 implemented already (relative dates for deadlines), but you still need bug 396026 to be implemented first.


> I don't see why we need a separate param, template and code.

I agree with Marc. We don't want separate code for this. Implementing bug 396026 would let admins create whines for all assignees at once. No alternate code or script is needed.


> My suggestion is to have checksetup.pl create such a whine (with its saved
> search and an "everybody" group) when installing a new Bugzilla.

You wouldn't need that. One single admin is free to create the whine and spam everybody, if that's what he wants.


(In reply to Marc Schumann [:Wurblzap] from comment #22)
> Current whining can do the job. Everything else is most definitely redundant.

I agree.


(In reply to Max Kanat-Alexander from comment #31)
>   I was actually thinking of creating a whole framework for special whines
> as a part of this.

I really don't think that's useful.

Comment 34

[Frédéric Buclin]

Comment on attachment 517419 [details] [diff] [review]
Special Whines

>=== added file 'specialwhines.pl'

>+                              whine_template => "email/whineatdeadline.txt.tmpl"};

We really don't want a separate script for this, as explained in the previous comments. Also, email/whineatdeadline.txt.tmpl has not been attached to the patch.

Comment 36

[Frédéric Buclin]

Bug 718289 is to make the deadline visible by everybody.