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).

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.

I was confused by the summary.

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.

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.

+ 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.

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.

+ Cleaned up some of the templates to behave more nicely with target_milestone.

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

*** Bug 149593 has been marked as a duplicate of this bug. ***

also implements a function to validate date fields

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

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 :)

(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.

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

(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?

This patch need that you drop table filddefs and run checksetup again after you apply it.

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.

Comment on attachment 156612 [details] [diff] [review] bug activity fixed Joel, I fixed the bug activity stuff, can you take a look?

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.

(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 :-)

you need to drop table fielddefs after applying the patch and then run checksetup again (bug 256004).

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.

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.

(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.

> - 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.

still need to drop table fielddefs and run checksetup again (bug 256004)

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.

(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.

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.

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 :(

Looks good to go in -- we have had this live for a month at a customer site using it.

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.

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 :)

This could use some basic documentation.

Comment on attachment 157809 [details] [diff] [review] patch Removing r? from obsolete attachment.

Comment on attachment 160568 [details] [diff] [review] v11: error with "edit several bugs" r=jouni

Targeting bug to 2.20 since the 2.20 feature freeze was canceled.

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

The documentation has been updated as part of bug 24789.