Closed Bug 103636 Opened 23 years ago Closed 19 years ago

Support for specifying a date on which a bug is expected to be resolved ('Deadline' field)

Categories

(Bugzilla :: Creating/Changing Bugs, enhancement)

2.14
enhancement
Not set
normal

Tracking

()

RESOLVED FIXED
Bugzilla 2.20

People

(Reporter: mschmitz, Assigned: michetti)

References

Details

Attachments

(6 files, 10 obsolete files)

29.92 KB, patch
Details | Diff | Splinter Review
5.62 KB, patch
Details | Diff | Splinter Review
5.53 KB, patch
Details | Diff | Splinter Review
16.55 KB, patch
Details | Diff | Splinter Review
1.46 KB, patch
Details | Diff | Splinter Review
21.17 KB, patch
jouni
: review+
Details | Diff | Splinter Review
This patch attached to this trouble ticket allows to specify a date a bug is
expected to be resolved. Group bits can used to restrict access to this field no
access, read-only access, read/write access). This concerns not only the bug
form, but also the activities log and the mail sent out when the trouble ticket
changes. A tiny script whineatoverdue.pl sends a email to tickets assignee if
the bug has not been resolved in time. The feature can be disabled in the
parameter section.
I had to add fix the query form since the list of attributes displayed in the
"Where the field(s)" selection list contains the *_effort fields even for users
that don't have access to these fields. Look at the "Target Date Query Patch"
for the necessary modifications.
SORRY, I mixed two bug reports, ignore my previous comment!

Here's the correct comment:
The original patch didn't allow to formulate a query for trouble tickets that
should have been fixed or have been fixed in a given period of time. This
problem is addressed by the "Target Date Query Patch".

In addition this patch fixes the query form with regard to the list of
attributes displayed in the "Where the field(s)" selection list. The list
contained the target date field even for users that don't have access to it.
The third patch - the Target Date Buglist Patch - fixes problems with the target
date fields in the bug list:

  1.  The target date didn't appear in output you get when pressing the
      "Long Format" button.
  2.  The same applies to the "Change Columns" dialog.
  3.  Defining the target date for multiple trouble tickets at once was
      not possible.

In addition it fixes a problem with queries using the target date (the "to"
date was not included).
Keywords: patch, review
Target Milestone: --- → Bugzilla 2.16
The question is, is this a feature enough people would want to make us add it
and, if so, should it be 2.16-targetted?

Dave?

Gerv
This bug is similar to bug 62370 that I know OEOne has expressed interest in and
that I suspect some folks at Netscape might also find useful.
This could be a new status that indicates its waiting for a resource to be
replaced.
Please, Matthew could you please explain what you meant when you said "This
could be a new status that indicates its waiting for a resource to be
replaced.".

As far as I can tell my patch addresses to problem Dave mentioned in the summary
of bug#62370: it adds support for "date based milestones" which can be used in
addition to normal "release base milestones". It doesn't affect the status of a
bug report.
We are currently trying to wrap up Bugzilla 2.16.  We are now close enough to
release time that anything that wasn't already ranked at P1 isn't going to make
the cut.  Thus this is being retargetted at 2.18.  If you strongly disagree with
this retargetting, please comment, however, be aware that we only have about 2
weeks left to review and test anything at this point, and we intend to devote
this time to the remaining bugs that were designated as release blockers.
Target Milestone: Bugzilla 2.16 → Bugzilla 2.18
I was confused by the summary.
Summary: Support for specifying a date on which a bug is expected to be resolved missing → Support for specifying a date on which a bug is expected to be resolved
I'd like to see this target date added to the 'Importance' sort (I looked through
the patches and it didn't look like it currently is a part of that sort).
Couple of comments about the patch: 

Do we really need to restrict access to this field besides the Param() at this
point?  It seems like it should just fit under "editbugs" for now until bug
110947 is fixed and then *any* field could be set to different permissions.  And
this just seems too specific- why could someone change the target milestone but
not the target date?

The javascript validation of the field is inconsistent with error reporting of
the rest of Bugzilla, shouldn't it (at this point) use PuntTryAgain() like
everything else (of course a validation function will have to be written).

I definitely would like to see this bug fixed though, and I'm willing to help in
any way, I'll probably patch it for my system anyway.
Attached patch My Patch (obsolete) — Splinter Review
Here's how I implemented it.  And I added 'target_date' to the Importance sort
(at the end)

I also am just using the Param(), no additional groupsets.

Oh- this needs better date error checking...  but any other comments?
I don't know the exact semantics of the "editbugs" permission bit, so maybe I
wrong in thinking it permits a user to change ANY field of any trouble ticket
he/she has access to. If this is true, I think restricting access to the target
date field is reasonable, since it concerns the work schedule, while modifying a
field like "Summary" does not. But you're right, the solution of bug 110947 will
give us the means for solving this kind of restrictions elegantely.

I don't care who checks the valitidy of the date the user entered. If
PuntTryAgain() is used for this all over Bugzilla, we should use it here as
well.
So which one of these date-milestone-approaches are we going to implement, or is
it "let's wait for custom fields" again?
I submitted bug#162998. It's basically asking for the same thing with one
difference--that the field be called Due Date. I think calling it Due Date will
make sense to far more people than Target Date. Anyone else agree?
Obviously it doesn't really matter what the field is called.  If you want the
page to show "Due Date", you can just change the templates. 

But either wording works for me.
*** Bug 162998 has been marked as a duplicate of this bug. ***
So in regards to comment#17. If I went through the effort of updating this patch
to work on 2.16, would it just be in vein because it would never be committed in
favor of bug#91037? If that is the case, then this bug should be marked to
depend on 91037.
One thing that I have in patch 71515 ("My Patch"), is integrating the target
date with the Importance sort.

Since it integrates a little more with the source, I think using this field as a
custom field would not work.  
I think the consensus is that the Due Date-style functionality would not work as
a custom field because of its unusual nature and interdependence with other fields.

Custom fields is more for things like "Text box", "multi-select" and "email
address".

So, updating one or more of the Due Date patches to the tip would hopefully not
be wasted effort. However, I think it might be a good idea, before people do
more work, to have a quick discussion in netscape.public.mozilla.webtools about
how exactly this should work. This makes sure we discover any sticky points
early on :-)

Gerv
Err. Why was that the consensus? Its not that hard to integrate them. The
consensus was that this wasn't suitable for the eestimated time remaining patch,
because of aall the dependancies. 'Expected resolve date' should have almost no
extra backend behind it, really.
I can't remember in which bug the discussion was, so I may have misremembered,
but I thought that the idea was that any field which needed special processing
(e.g. linking due date to severity) couldn't really be custom.

Gerv
gerv: right, but theres no such linkage here...
<shrug> OK, then. Please don't update it :-)

Gerv
Well, in My Patch I do link it to severity (well, the importance sort).  But if
that's something most people would not care about, then it can be a custom field.

For my purposes though, I would rather see the target date affect the sort in
the Importance sort. 
Yes I think the due date should affect the Importance sort.
Attached patch Patch v.3 (obsolete) — Splinter Review
+ Updated to HEAD
+ New bugmail is processed correctly
+ Activity logging improved
+ Removed target_date searching on query.cgi if param turned off
+ Can enter a target_date on bug entry
+ Moved target_date for show_bug.cgi underneath Severity, since it is tied into
Severity/Priority in the sorts.
Attachment #71515 - Attachment is obsolete: true
I'm against this - this looks like the sort of thing which would be perfectly
handled by a custom field.
> I'm against this - this looks like the sort of thing which would be perfectly
> handled by a custom field.

I disagree, because it is tied into the Importance sort.
Attached patch Patch v.4Splinter Review
+ Cleaned up some of the templates to behave more nicely with target_milestone.
Attachment #102901 - Attachment is obsolete: true
Hmmm.. Whilst true, I don't think that we're going to want to create fixed
columns in the bugs table just because a field could be tied to importance. What
do others think? gerv? justdave? myk?

Can't we have the importance -> sort order mapping happen in the query.cgi
template? That would probably make more sense, allowing the admin to customise
the list as requried, The target milestone isn't counted in the importance ATM
either, mind you.
This patch would probably make a good short-term fix....

On the other hand, I think the correct approach for long-term is to set up some
sort of interface where the admin (or maybe even the user?) can decide what
"Importance" means, i.e. which columns are used at what weight to determine
importance, and allow that interface to include custom fields. (see bug 77472)

So the real question is how fast can bug 77472 get implemented?
I agree with Dave; the "importance sort" is too weak a reason to check this in,
when we know custom fields are coming down the pipe (because Zippy needs them.)
If people need the importance sort, it should be a six-line customisation (3
lines in the template, 3 in buglist.cgi.)

But also yes, in future, we need to make it possible for admins to define the
sort orders available.

Gerv
I would very much like to have this bug put in so the due date is included in
the importance sort. please please please! otherwise can you please give the 6
line patch that allows me to do it myself?
> I would very much like to have this bug put in so the due date is included in
> the importance sort. please please please! otherwise can you please give the 6
> line patch that allows me to do it myself?

The six line patch would be for a custom sort order when custom fields are
implemented (which they aren't at the moment, but will be reasonably soon.) In
the mean time, feel free to apply the patch in this bug to your Bugzilla.

Gerv
Hardware: PC → All
Target Milestone: Bugzilla 2.18 → Bugzilla 2.20
*** Bug 149593 has been marked as a duplicate of this bug. ***
also implements a function to validate date fields
Attachment #154136 - Flags: review?(kiko)
Comment on attachment 154136 [details] [diff] [review]
implements deadline for bugs and searchs by deadline

Missed CGI.pl where you need to take it out of the activity log

Missed BugMail where you need to keep it from getting built into messages

ValidateDate seems a bit restrictive.  I believe the 2004-04-01 and 2004-1-1
should be equally valid.

Also, ValidateDate seems oddly placed in Bug.pm and should probably live in
Bugzilla::Util
Attachment #154136 - Flags: review-
Assignee: myk → michetti
you also need to make the boolean charts work with the deadline field

that means....

SqlifyDate() needs to be adapted to understand both dates before now (default)
and dates from now (indicated by preceding the number with a + sign).

-    if ($str =~ /^-?(\d+)([dDwWmMyY])$/) {   # relative date
-        my ($amount, $unit, $date) = ($1, lc $2, time);
+    if ($str =~ /^(-|\+)?(\d+)([dDwWmMyY])$/) {   # relative date
+        my ($sign, $amount, $unit, $date) = ($1, $2, lc $3, time);

And you need to teach the code how to handle the date field...

+        
"^deadline,(?:lessthan|greaterthan|equals|notequals),(-|\\+)?(\\d+)([dDwWmMyY])\$"
=> sub {
+             $v = SqlifyDate($v);
+             $q = &::SqlQuote($v);
+        },

(In reply to comment #41)
> (From update of attachment 154136 [details] [diff] [review])
> Missed CGI.pl where you need to take it out of the activity log
> 
> Missed BugMail where you need to keep it from getting built into messages

  Sorry Joel, can you explain this a little better? 
 
> ValidateDate seems a bit restrictive.  I believe the 2004-04-01 and 2004-1-1
> should be equally valid.
> 
> Also, ValidateDate seems oddly placed in Bug.pm and should probably live in
> Bugzilla::Util
  
  Ok, I will make this changes
  Thanks for the patch :)

Attachment #154136 - Flags: review?(kiko)
(In reply to comment #44)
> (In reply to comment #41)
> > (From update of attachment 154136 [details] [diff] [review])
> > Missed CGI.pl where you need to take it out of the activity log
> > 
> > Missed BugMail where you need to keep it from getting built into messages
> 
>   Sorry Joel, can you explain this a little better? 
>  

In both of those places, people who are not mmbers of the timetracking group
have to be handled specially so that they do not see the changes to the field in
 showactivity and so that they do not get notified of the field in bugmail.
Attachment #154136 - Attachment is obsolete: true
Attachment #156306 - Flags: review?(bugreport)
Comment on attachment 156306 [details] [diff] [review]
some changes in ValidateDate and BugMail


Some slight bitrot already

Also.... When a date fails validation
Undefined subroutine &Bugzilla::Util::ThrowUserError called at Bugzilla/Util.pm
line 191.

Deadline field in bugmail needs some formatting.... it shows the time as
well....

	   What    |Removed			|Added
----------------------------------------------------------------------------
	   Deadline|				|2004-07-05 00:00:00


Other than that, looks pretty good.

Fix those and it will be r=joel
Attachment #156306 - Flags: review?(bugreport) → review-
(In reply to comment #47)
> (From update of attachment 156306 [details] [diff] [review])
> 
> Some slight bitrot already
> 
> Also.... When a date fails validation
> Undefined subroutine &Bugzilla::Util::ThrowUserError called at Bugzilla/Util.pm
> line 191.
> 
> Deadline field in bugmail needs some formatting.... it shows the time as
> well....
> 
> 	   What    |Removed			|Added
> ----------------------------------------------------------------------------
> 	   Deadline|				|2004-07-05 00:00:00
> 
> 
> Other than that, looks pretty good.
> 
> Fix those and it will be r=joel
> 

I fix this bugs, but there is one thing I don't know what to do.
I created the field deadline in table bugs, and I also include a
AddFDef("deadline", "Deadline", 1) to include this field description on table
fielddefs. The problem is that when I apply the patch after running
checksetup.pl, the sortkey field for deadline in fielddefs became 1, and because
other field already have this sort key, the mail send when a new bug is created
don't include the Deadline.
If I drop the fielddefs table and run checksetup.pl again, the problem is gone.
This occurs because AddFDef increment the variable $headernum every time it is
used, but when I change checksetup this variable will be 1.
Can anybody help?
Attached patch bugs fixed (obsolete) — Splinter Review
This patch need that you drop table filddefs and run checksetup again after you
apply it.
Attachment #156306 - Attachment is obsolete: true
Attachment #156439 - Flags: review?(bugreport)
Comment on attachment 156439 [details] [diff] [review]
bugs fixed

There are a few items that still need to be cleaned up, but I think we can do
that as a distinct bug after this lands...

specifically, the display column for deadline needs to be formatted for just
the year/month/day as does the activity log entry.
Attachment #156439 - Flags: review?(bugreport) → review+
Attachment #156439 - Flags: review?(kiko)
Attached patch bug activity fixed (obsolete) — Splinter Review
Attachment #156439 - Attachment is obsolete: true
Attachment #156612 - Flags: review?(kiko)
Attachment #156439 - Flags: review?(kiko)
Comment on attachment 156612 [details] [diff] [review]
bug activity fixed

Joel, I fixed the bug activity stuff, can you take a look?
Attachment #156612 - Flags: review?(bugreport)
Comment on attachment 156612 [details] [diff] [review]
bug activity fixed

>Index: CGI.pl
>+            if ($fieldname eq 'deadline') {
>+                my $olddeadline = str2time($removed);
>+                $change{'removed'} = time2str("%Y-%m-%d", $olddeadline);
>+                my $newdeadline = str2time($added);
>+                $change{'added'} = time2str("%Y-%m-%d", $newdeadline);
>+            } else {
>+                $change{'removed'} = $removed;
>+                $change{'added'} = $added;
>+            }

This change would be much cleaner if you simply changed the values of $added
and $removed *before* they were added to the hash. Then the part that says

		$change{'removed'} = $removed;
		$change{'added'} = $added;

Wouldn't need to be changed.

>Index: post_bug.cgi
>+if ((UserInGroup(Param("timetrackinggroup"))) && ($::FORM{'deadline'})) {

Notice this line, and then:

>Index: process_bug.cgi
>+    if ($::FORM{'deadline'}) {

See what's missing? :-)

>+        Bugzilla::Util::ValidateDate($::FORM{'deadline'});
>+        DoComma();
>+        $::query .= "deadline = " . SqlQuote($::FORM{'deadline'});
>+    } else {
>+        DoComma();
>+        $::query .= "deadline = NULL" ;
>+    }

You could also move DoComma() out of the if (since it's unconditional) and
perhaps even do something like:

  $::query.= "deadline = ";
  if (... deadline ...) {
     Validate...
     $::query .= SqlQuote ..
  } else {
     $::query .= "NULL";
  }

>Index: Bugzilla/Search.pm
>+    if (&::UserInGroup(Param('timetrackinggroup'))){

You could use Bugzilla->user->in_group here if you liked..

>Index: Bugzilla/Util.pm
>+sub ValidateDate {

Okay, but if you think this should be moved to Util.pm, then maybe ValidateTime
should too. Can you file a new bug for this?

>Index: template/en/default/bug/edit.html.tmpl

Note that the change here may be invalidated when bug 252151 lands.

>Index: template/en/default/search/form.html.tmpl

Remember to show me how the search form looks now.

Looking good with the above remarks.
Attachment #156612 - Flags: review?(kiko) → review-
(In reply to comment #53)
> >+            if ($fieldname eq 'deadline') {
> >+                my $olddeadline = str2time($removed);
> >+                $change{'removed'} = time2str("%Y-%m-%d", $olddeadline);
> >+                my $newdeadline = str2time($added);
> >+                $change{'added'} = time2str("%Y-%m-%d", $newdeadline);
> >+            } else {

And actually, this could be rewritten as:

  $removed = time2str("%Y-%m-%d", str2time($removed));
  $added = time2str("%Y-%m-%d", str2time($added));

And you don't need "use Bugzilla::Bug" anymore since ValidateDate is now in
Bugzilla::Util :-)
Attached patch Patch more clean (obsolete) — Splinter Review
Attachment #157363 - Attachment is obsolete: true
Attached patch patch (obsolete) — Splinter Review
you need to drop table fielddefs after applying the patch and then run
checksetup again (bug 256004).
Attachment #156612 - Attachment is obsolete: true
Attachment #157491 - Flags: review?
Comment on attachment 157491 [details] [diff] [review]
patch

>Index: process_bug.cgi
>@@ -788,6 +788,16 @@ if (UserInGroup(Param('timetrackinggroup
>             }
>         }
>     }
>+
>+    DoComma();
>+    $::query .= "deadline = ";
>+    if ((UserInGroup(Param("timetrackinggroup"))) && ($::FORM{'deadline'})) {

I tricked you here, unfortunately -- this is already inside an if statement
that is checking is the user is in the timetracking group. It can be reverted.
r=kiko with that, let's see what jouni thinks since I'm sitting next to you
usually :o)

BTW, there should be no need to drop fielddefs unless you had already changed
the column -- it won't be a problem if you never applied the patch before.
Attachment #157491 - Flags: review?(jouni)
Attachment #157491 - Flags: review?
Attachment #157491 - Flags: review+
Ah, sorry, hadn't noticed the bug report about fielddefs. Ignore last part of
comment.
Comment on attachment 157491 [details] [diff] [review]
patch

Misc notes:

- Change columsn shows "deadline" with a small d; I want it to be big. :-)
- Why is deadline so high up in boolean charts selection list? It's not that
important, I guess...
- Why do deadlines get shown with the time (00:00:00) included in buglists?


>Index: CGI.pl
>===================================================================
>             $change{'attachid'} = $attachid;
>             $change{'removed'} = $removed;
>             $change{'added'} = $added;
>+            
>             push (@$changes, \%change);

What's this?

>Index: checksetup.pl
>===================================================================
>Index: colchange.cgi
>===================================================================
>-                       "percentage_complete")); 
>+                       "percentage_complete","deadline")); 

Nit: Space after the comma.

>Index: Bugzilla/Util.pm
>===================================================================

>+sub ValidateDate {
>+    my ($date) = @_;
>+
>+    my $ts  = str2time($date);
>+    my $date2 = time2str("%Y-%m-%d", $ts);
>+
>+    $date =~ s/(\d+)-0*(\d+?)-0*(\d+?)/$1-$2-$3/; 
>+    $date2 =~ s/(\d+)-0*(\d+?)-0*(\d+?)/$1-$2-$3/;
>+
>+    if ($date ne $date2) {
>+        ThrowUserError('illegal_date', {date => $date});
>+    } 
>+}

This is horrible since most of the cultures don't use yyyy-mm-dd for date
entry. But until we fix it, make the error message tell the format extra
clearly. 

>Index: template/en/default/bug/create/create.html.tmpl
>===================================================================
>+      <input name="deadline" size="10" maxlength="10"
>+      value="[%default.dealinefrom.0 FILTER html %]"> (YYYY-MM-DD)

I suppose you mean "deadlinefrom"? Set this as a filterexception, it doesn't
need HTML filtering.

>Index: template/en/default/search/form.html.tmpl
>===================================================================

>+[%# Deadline and Work Time %]

Nit: That block contains nothing about Work Time - don't talk about it :-)

The filterexception issues mentioned above apply here too.

>+      <fieldset>
>+        <legend><strong>Deadline</strong></legend>
>+<dl>
>+  <dt>[% terms.Bugs %] with deadline between:</dt>

Do you have a reason for this perverted indentation?-) These fieldset things
are absolutely horrible, but not the subject of this bug.

>+    value="[%default.deadlineto.0 FILTER html %]">
>+    <br>(YYYY-MM-DD)

Why this <br>?

I'm afraid of the overall dominance of this deadline thing. It's probably a
fairly important search criteria for sites using it, but now it's both hidden
and clumsy. How would you like an elegant one-line UI below Keywords:

Deadline: between [	     ] and [	       ] (YYYY-MM-DD) 

(wonder if that would break the ui too badly)

If you reasonably can, get Myk's opinion on the search form stuff.
Attachment #157491 - Flags: review?(jouni) → review-
(In reply to comment #60)
> >+    if ($date ne $date2) {
> >+        ThrowUserError('illegal_date', {date => $date});
> >+    } 
> >+}
> 
> This is horrible since most of the cultures don't use yyyy-mm-dd for date
> entry. But until we fix it, make the error message tell the format extra
> clearly. 

This is unfair to ask: other parts of the code already trigger this error and
it's certainly not in the scope of this bug to audit them and ensure they all
use the same date format. I'm happy with opening a new bug for that.

Status: NEW → ASSIGNED
> - Why is deadline so high up in boolean charts selection list? It's not that
> important, I guess...

  The boolean charts selection is ordered by the sort key in table fielddefs,
and because of bug 256004, when you apply the patch, the deadline sortkey will
be 1, and then it will apear on the second position (bugid also have a sortkey
1). So drop table fielddefs and run checksetup again to get deadline on the
correct place on boolean charts selections list.
Attached patch patch (obsolete) — Splinter Review
still need to drop table fielddefs and run checksetup again (bug 256004)
Attachment #157491 - Attachment is obsolete: true
Attachment #157809 - Flags: review?(kiko)
I'm still thinking about the UI for this.  At the moment it's over-prominent and
messy, but it's also well-distinguished from unrelated elements and relatively
understandable.  I think it's OK in its current incarnation, although I'm open
to suggestions for improving it.
(In reply to comment #61)
> This is unfair to ask: other parts of the code already trigger this error and
> it's certainly not in the scope of this bug to audit them and ensure they all
> use the same date format. I'm happy with opening a new bug for that.

I didn't say you had to modify the error message used by those two other
callsites. You can also parameterize the error so that you can specify format
information to be shown in an additional parameter. If there is no additional
information, then the error message can remain as it is now.

The bottom line is this: you just can't add a date based input field into the
bug form and not have any type guide in it. A typical Finnish user, for example,
would first try d.m.yyyy, then perhaps yyyy/mm/dd, yyyy/dd/mm and then give up.
Those who have been dealing with international standards might then try
yyyy-mm-dd, but at that point, the user has already been toyed up a bit too much. 

If you can't fit the format guide text into the entry form because of layout
reasons (see advanced bug query form for an example), then you must make the
error contain some useful advice. It would, of course, be much better to get the
format hint into the input form itself. Sorry for not mentioning this the last time.

Filed bug 258026 about the new charting containing the same problem.
Attachment #156612 - Flags: review?(bugreport)
(In reply to comment #65)
> I didn't say you had to modify the error message used by those two other
> callsites. You can also parameterize the error so that you can specify format
> information to be shown in an additional parameter. If there is no additional
> information, then the error message can remain as it is now.

Oh. This definitely makes sense; sorry to not have understood your initial
request. Adding an optional format argument is easy.
Attached patch new illegal date message (obsolete) — Splinter Review
now the illegal_date error display a message about the format that should be
used if the parameter 'format' exist.
also, i fix a problem with the select box from boolean chars. Now it only
display deadline if the user is in timetracking group.
Attachment #157809 - Attachment is obsolete: true
Attachment #159036 - Flags: review?(jouni)
Comment on attachment 159036 [details] [diff] [review]
new illegal date message

r=jouni

Sorry it took so long, I was ridiculously busy with some exams and work :(
Attachment #159036 - Flags: review?(jouni) → review+
Looks good to go in -- we have had this live for a month at a customer site
using it.
Flags: approval?
Flags: approval? → approval+
Erm, sorry, my mistake.  We're in 2.20 freeze, and this is a bigger change than
should go in at this point.  Please hold until we branch 2.20, at which point
this can go in.
Flags: approval+ → approval?
DoComma;
    $::query .= "deadline = ";
    if ((UserInGroup(Param("timetrackinggroup"))) && ($::FORM{'deadline'})) {
	$::query .= SqlQuote($::FORM{'deadline'});
    } else {
	$::query .= "NULL" ;
    }

  when you change several bugs at once, all bugs deadline will be "updated" to
NULL.

  Thank you Tiago :)
Attachment #159036 - Attachment is obsolete: true
Target Milestone: Bugzilla 2.20 → Bugzilla 2.22
Severity: normal → enhancement
This could use some basic documentation.
Flags: documentation?
Comment on attachment 157809 [details] [diff] [review]
patch

Removing r? from obsolete attachment.
Attachment #157809 - Flags: review?(kiko)
Attachment #160568 - Flags: review?(jouni)
Comment on attachment 160568 [details] [diff] [review]
v11: error with "edit several bugs"

r=jouni
Attachment #160568 - Flags: review?(jouni) → review+
Whiteboard: patch awaiting approval
Targeting bug to 2.20 since the 2.20 feature freeze was canceled.
Target Milestone: Bugzilla 2.22 → Bugzilla 2.20
Flags: approval? → approval+
Checking in CGI.pl;
/cvsroot/mozilla/webtools/bugzilla/CGI.pl,v  <--  CGI.pl
new revision: 1.223; previous revision: 1.222
done
Checking in buglist.cgi;
/cvsroot/mozilla/webtools/bugzilla/buglist.cgi,v  <--  buglist.cgi
new revision: 1.268; previous revision: 1.267
done
Checking in checksetup.pl;
/cvsroot/mozilla/webtools/bugzilla/checksetup.pl,v  <--  checksetup.pl
new revision: 1.327; previous revision: 1.326
done
Checking in colchange.cgi;
/cvsroot/mozilla/webtools/bugzilla/colchange.cgi,v  <--  colchange.cgi
new revision: 1.45; previous revision: 1.44
done
Checking in globals.pl;
/cvsroot/mozilla/webtools/bugzilla/globals.pl,v  <--  globals.pl
new revision: 1.283; previous revision: 1.282
done
Checking in long_list.cgi;
/cvsroot/mozilla/webtools/bugzilla/long_list.cgi,v  <--  long_list.cgi
new revision: 1.42; previous revision: 1.41
done
Checking in post_bug.cgi;
/cvsroot/mozilla/webtools/bugzilla/post_bug.cgi,v  <--  post_bug.cgi
new revision: 1.94; previous revision: 1.93
done
Checking in process_bug.cgi;
/cvsroot/mozilla/webtools/bugzilla/process_bug.cgi,v  <--  process_bug.cgi
new revision: 1.224; previous revision: 1.223
done
Checking in Bugzilla/Bug.pm;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/Bug.pm,v  <--  Bug.pm
new revision: 1.48; previous revision: 1.47
done
Checking in Bugzilla/BugMail.pm;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/BugMail.pm,v  <--  BugMail.pm
new revision: 1.21; previous revision: 1.20
done
Checking in Bugzilla/Search.pm;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/Search.pm,v  <--  Search.pm
new revision: 1.73; previous revision: 1.72
done
Checking in Bugzilla/Util.pm;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/Util.pm,v  <--  Util.pm
new revision: 1.17; previous revision: 1.16
done
Checking in template/en/default/filterexceptions.pl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/filterexceptions.pl,v 
<--  filterexceptions.pl
new revision: 1.28; previous revision: 1.27
done
Checking in template/en/default/bug/edit.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/edit.html.tmpl,v  <--
 edit.html.tmpl
new revision: 1.48; previous revision: 1.47
done
Checking in template/en/default/bug/show-multiple.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/show-multiple.html.tmpl,v
 <--  show-multiple.html.tmpl
new revision: 1.21; previous revision: 1.20
done
Checking in template/en/default/bug/create/create.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/create/create.html.tmpl,v
 <--  create.html.tmpl
new revision: 1.37; previous revision: 1.36
done
Checking in template/en/default/global/field-descs.none.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/global/field-descs.none.tmpl,v
 <--  field-descs.none.tmpl
new revision: 1.5; previous revision: 1.4
done
Checking in template/en/default/global/user-error.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/global/user-error.html.tmpl,v
 <--  user-error.html.tmpl
new revision: 1.81; previous revision: 1.80
done
Checking in template/en/default/search/form.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/search/form.html.tmpl,v 
<--  form.html.tmpl
new revision: 1.29; previous revision: 1.28
done
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Whiteboard: patch awaiting approval
Blocks: 283361
Summary: Support for specifying a date on which a bug is expected to be resolved → Support for specifying a date on which a bug is expected to be resolved ('Deadline' field)
The documentation has been updated as part of bug 24789.
Flags: documentation?
QA Contact: matty_is_a_geek → default-qa
You need to log in before you can comment on or make changes to this bug.