when I do a bugzilla query and try to search for all new bugs filed in the past 2, 3 or 7 days, the results are always for the past 24 hours. This was working last week.

update url so it will exhibit problem

That query doesn't ask for new bugs filed in the last 2, 3, or 7 days. It asks for new bugs filed between "" (blank) and "now", which have been changed in the last 2 days. For some reason (e.g., a bug), the code interprets "" as "today", so it finds all new bugs filed between midnight this morning and now. Don't put a "2" in the "changed in the last ___ days" field; instead, put a date in the date range field.

A few points: 1. Specific dates do not work nearly as well as relative dates for many queries, especially for canned queries that are bookmarked or put in a webpage. 2. Limiting a query to bugs that are new in the last "n" days is a very useful way to cut a result set down to size when hunting for an existing report of a regression when you can't be sure that the regression happened today. 3. For people who live halfway around the globe or even just a few timezones away, the "View Bugs Already Reported Today" link on Mozilla's Bugzilla is nowhere near as useful for finding reports of regressions in the current nightly as a canned query that would look for bugs reported today /and/ yesterday. 4. Previously the "Changed in the last __ days" field could be used in conjunction with any of the "Where the field(s)" items to search, for instance, for bugs whose resolution has changed in the last week. ... and an observation: The "Changed in the last __ days" field still works as expected when the "Where the field(s)" field is empty -- presumably it still does when that field isn't empty, but the "" in the "dates ___" field equating to today is further limiting the search so you'd never know. Personally, I wouldn't mind if this functionality was moved to the boolean chart part of the form, even though it would not be as clear ( [bug creation] [ <= ] [2] ), but specific date searching just can't do all the work that relative date searching can do. If "" in the "dates ___" field is equating to today, that is a bug -- empty fields should not limit a search at all.

D'oh! A very simple workaround: put 2000-01-01, or any other epochal date prior to the date "n" days ago you want to limit the search to, into the "dates ___" field. The result: a seach for bugs changed in the last "n" days that also had the field "[Bug creation]" changed in the period from 2000-01-01 to now, which works as well as ...that also had the field "[Bug creation]" changed in the period from "" (whenever) to now -- so long as 2000-01-01 was at least "n" days ago.

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

generalizing summary I there any chance this will get fixed soon? Some of my bookmarks have been broken for quite a while...

Kathy wants to do searches "where bug creation changed in the last N days". This doesn't seem possible with the current query form. The "changed in the last __ days" item does not modify the items on the following line which is why you're getting unexpected results. Perhaps we should add "bug created" to the first boolean chart dropdown and "changed since N days ago" to the second dropdown. Then kathy could type in "2" and have a canned query uses relative dates. Also, unless i misunderstand sean's suggestion. it doesn't work. It searches for bugs entered since the beginning of time, that have been chagned in the last 2 days which is the same as "bugs changed in the last two days". "Changed in the last _ days" means "any field in the bug has changed" there is no way to specifiy which field changed.

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

The attachment demonstrates a workaround that will work for permanent HREFs in a document; it might be possible to convert it into a javascript bookmarklet. It works by building up the link with document.write including a call to a function that returns the date 'n' days ago, corrected to Mountain View standard time, as a string formatted as mm/dd/yyyy. The demo creates links to a buglist and query for all UNCONFIRMED and NEW Browser and Mailnews bugs created between one day ago and now (24-48 hours' worth). Changing the query is annoying but not difficult; it's just a matter of cutting and pasting parts of the query string you want to use. Excerpting the portion that does the work: &chfield=%5BBug+creation%5D&chfieldfrom=' + pastdate(1) + '&chfieldto=Now Each time the link is invoked, the pastdate(n) function recalculates the date 'n' days ago. Dawn is right, the workaround I mentioned earlier doesn't work, and shouldn't ...but it /did/, at the time that I added that comment. The simplest way I can think of fixing this bug properly would be to add, to the first dropdown of the boolean charts, "Days since bug created" as well as "Creation date"; that would allow a straightforward query term: [Days since bug created] [less than] [2]

a) it seems improbable that this could block a bug that's already fixed. Should the dependency be removed? b) has this already been fixed? I have a bookmarked query that grabs anything changed in the last 3 days that I use all the time, and it has worked just fine for the last few months... &changedin=3&chfieldfrom=&chfieldto=Now

Updating summary to reduce confusion... From: "query for changes in last n days doesn't work" To: "query for changes to specific field in last n days not working" Dave: a) As for this bug blocking bug 30978, it still does. The workaround demo'd in the attachment to this bug is in use there, but if this bug gets fixed, the workaround there should be removed in favour of simple readable code -- so the dependency remains so that the owner of 30978 will be alerted when this bug gets fixed. b) yes, it's perfectly possible to seach for bugs where *any* change has been made in the last n days, but if you are interested in changes to only one field, it's another story. A query like ... &changedin=3&chfield=%5BBug+creation%5D&chfieldfrom=&chfieldto=Now ... used to find bugs created in the last 3 days, but there's currently no way to express that in bugzilla. If chfield is not empty, chfieldfrom can't be either; if it is, you get "Zarro Boogs". However, testing with today's Bugzilla 2.11, the URL above *does* work. The difference: rather than "...&changedin=2&chfield=%5BBug+creation%5D&chfieldfrom=&chfieldto=Now" it reads "...&changedin=2&chfield=%5BBug+creation%5D" Now that's tricky. I'd call that another workaround, because while bookmarks can easily be handcrafted like that, URLs resulting from clicking on [Submit] on the query.cgi page all include "&chfieldfrom=". Put another way, there's still no way to fill out the form on query.cgi to create a working "changes to specific field in last n days" link ... normally one only bothers paring the excess off a buglist.cgi URL that already works!

Would it break anything if the chfieldfrom value were changed so that if it's null it's treated as "the beginning of time" instead of "today"? Seems to me like that would fix this situation, and it seems like an easy fix. (i.e. in the code that's parsing it, if it's null, set it to 1970).

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

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

CC:ing self. This is very frustrating for testers, who often wish to know new bugs in past <n> days in their component. Thanks to Sean for the workaround!

Does this really cover the subject of bug 40410? ("Bugs reported today" are bugs reported since previous midnigth in Mountain View. When I look at the list just after 10:00 [AM] in Finnish time, the list is empty.)

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

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

Mass moving to new product Bugzilla...

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.

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

anyone working on this ?

See also bug 43551.

patch for enhancement 149246 allows specification of relative times in the date fields: \d+[dwmy] 5d 5 days ago 0d today midnight (server local time) 0w beginning this week 1w beginning of last week 1m beginning of last month 0y beginning of this year so just use [creation time] (from) 5d (to) now to find bugs created today and previous 5 days.

Things are in a mess here. Let me remind the field names first: "Only bugs changed in the last X days" -> changedin "Only bugs where any of the fields" -> chfield "were changed between X and Y" -> chfieldfrom, chfieldto and now let me sort things out: 1) There is a bug which causes an empty chfieldfrom to be treated as last midnight. Bugzilla uses Date::Parse to parse chfieldfrom and chfieldto, and it is Date::Parse that treats an empty string as last midnight. 2) From both the Query page UI and the bugzilla search code, it follows that changedin and chfield are independent. changedin means "Changed in last X days, period". Thus, this bug is not really a bug; it's invalid. 3) However, I understand (by the older comments on this bug) that previous bugzilla versions worked differently; changedin were taking chfield into account (though I recall the UI to be the same, which means it was kind of ambiguous). Which means that this bug might be valid. 4) The "View bugs already reported today" link is incorrect. It searches for changedin=1 and chfield="Bug creation". It wouldn't work were it not for the Date::Parse bug mentioned in (1) above. The link must be changed to make use of the enhancement of bug 149246. I propose the following: a) Before doing anything else, correct "View bugs already reported today". b) Make improvements to the UI so that no-one thinks that changedin may be related to chfield. c) Correct problem (1) above. d) Document the enhancement of bug 149246. Right now the Query page says "YYYY-MM-DD" after chfieldfrom and chfieldto, which is no longer accurate. There is nowhere any clue that relative dates can be used. This bug's summary can be changed to show we'll do (b). Bug 43551 must be marked invalid or a duplicate of this. I don't know if separate bugs should be filed for (c) and (d).

See also bug 138959.

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

> Document the enhancement of bug 149246. If I'd known about that functionality I never would have filed the duplicate bug 177697 4 months after bug 149246 was resolved. And nobody caught the fact that it was a duplicate (with functionality that's already existed for over half a year now), until my attention was brought to this bug and I read through all of the comments here.

Here is what I propose for the UI. After the relative dates enhancement (bug 149246) I believe the changedin field is useless, so I've got rid of it; instead, you'll specify chfieldfrom and chfieldto and leave chfield empty. buglist.cgi will continue to process changedin so that existing links will continue to work. A changedin=1 combined with chfield=[Bug creation] will be a special case equivalent to chfieldfrom=1d and chfield=[Bug creation], so that the "All today's bugs" links continue to work until corrected. If we arrive at a UI we agree on, I'll probably work on a patch.

That UI looks good, except that you will need an "Any" option in the list of changed things - selecting that will emulate the behaviour of the missing box. It should be selected by default. CCing Myk, as owner of the User Interface componet, for comments. Gerv

If "Any" were added to the list of fields, it would read Only bugs changed between ... and ... in any of the fields [Any] which is not correct. You can't write "in the fields" instead of "in any of the fields", or it won't be clear what a multiple selection would mean. I couldn't think of a better wording. That's why I marked the fields field optional and proposed an empty selection to mean any change.

Why not simply have ALL of the fields selected by default, thereby emulating "Any". If somebody wants to narrow it down to one or more specific fields, they can click on those (thereby un-highlighting everything).

a) said query would produce a monstrous SQL query if someone actually ran it with all the fields selected b) some platforms don't unselect the rest of the list when you click on an item that's already selected (notably Mac)

Nevermind that then... (I should have realised.) Attaching something that makes more sense in every circumstance, and makes use of an explicit - Any - entry per comment 31 that can be selected by default.

Nevermind that then... (I should have realised.) Attaching something that makes more sense in every circumstance, and makes use of an explicit - Any - entry per comment 31 that can be selected by default.

Ack! Sorry about the duplicate comment.

Hmm. That kind of implies that if you select multiple fields that *all* of them had to have changed. Perhaps the text "or" should be added to the right of the list box.

The issue with the third attachment is that it says: Only bugs changed between X and Y | where the field Z | changed to W. when it should say: Only bugs changed between X and Y | where the field Z changed | to W. if you see what I mean. Hmm. We shouldn't be labelling fields "optional" at all, because every field on the search page is optional. So, you are right. No selection (or everything selected) should mean "any". And the text should be: Only bugs changed between: [ ] and [ ] (YYYY-MM-DD or relative dates) where there was a change in: _________________ | | | | | | | | |_________________| and it changed to: [ ] How's that look? Gerv

> if you see what I mean. Not really. <grin> The English sentence remains the same, regardless of where the break for the input is. It's also the most clear presentation of expected query output that I've seen so far. > where there was a change in: > and it changed to: Except, again, if none of the fields are selected it's pretty unclear exactly what the query is going to do. It would be nice to not have to add several "help" sentences to explain that selecting nothing actually means "any field". Also, purely gramatically, there would be a problem if more than one thing were picked because you can't use plural / it. (So it would have to read "and it/they changed to", which is awkward - although better.) Another possibility is to split it up into three different sections as per: Only bugs changed between: [ ] and [ ] (YYYY-MM-DD or relative dates). Limit above query to where a field was changed to: [ ]. Further limit both date and field changes above to just one or more of the following selected fields: +---+ | | +---+ But I still prefer http://bugzilla.mozilla.org/attachment.cgi?id=117632&action=view with the addition of "Or" to the right of the list box. (I don't actually understand the objection in the first paragraph of comment 39.)

> Not really. <grin> The English sentence remains the same, regardless of where > the break for the input is. Not true. Take both examples: Only bugs changed between X and Y | where the field Z | changed to W. Only bugs changed between X and Y | where the field Z changed | to W. and then chop off the end (because you aren't using that last field): Only bugs changed between X and Y | where the field Z Only bugs changed between X and Y | where the field Z changed Only one of these still makes sense. > It would be nice to not have to add several "help" sentences to explain that > selecting nothing actually means "any field". We don't have to do this, because it's true of every other multi-select on the page. > Another possibility is to split it up into three different sections as per: Your wording is far too lengthy. Compare with the amount of labelling and explanatory text on the rest of the form (which is still fairly easy to understand.) This is what we should be aiming for. I object to attachment 117632 [details] with added "or" because it would be ugly. :-) However, I take your grammatical point. New suggestion: Only bugs changed between: [ ] and [ Now ] (YYYY-MM-DD or relative dates) where there was a change in: _________________ | | | | | | | | |_________________| and the new value was: [ ] Gerv

New proposal that addresses comments in bug 41, while also dealing with the "Any" issue.

Hmm. Make that simply "issues in comment 41".

Brill, except that you can remove -Any- from the dropdown, and please add colons after each explanatory phrase. Gerv

> Brill, At first, I thought you were addressing somebody I didn't know, then I realised what you'd meant. <grin> > you can remove -Any- from the dropdown Er - will do. I'm still not happy about the fact that people may not realise that not selecting anything will imply "any". However, since, despite that, this will be a definite improvement to what we currently have, I'm not about to stand in the way of progress. > please add colons after each explanatory phrase Done. (The next step has to be taken up by somebody else.)

Comment on attachment 116789 [details] Proposed query UI I also like the last solution. I also like my original version, (attachment 116789 [details]), but without the "optional" marks. I'd also prefer not having a colon after "between", but I don't really care. I'll probably start working on a patch, if there are any serious objections please raise them early.

I'm working on a patch, and in the meantime I'd like some more comments on the UI. I hate prolonging the discussion, but I thought it was important to keep the box small, so I used something more close to my original UI version than that of attachment 117727 [details].

> I thought it was important to keep the box small, so I used something more > close to my original UI A few comments: 1. The important parts of the UI (which should be discussed) are the wording and layout, not the font size or whitespace between text and graphic which can be easily tweaked. (Attachment 117727 [details] can be easily be reduced in size.) 2. The 1st example in attachment 118448 [details] is better than the 2nd. Having additional "help text" at the bottom in the 2nd just doesn't look right to me, and I miss the (appropriate in its context) help text underneath the from and to in the 1st. (We shouldn't be concerning ourselves with letting people know what happened to the old interface but rather simply instructing them in how to use the new one.) 3. The 1st example in attachment 118448 [details] seems to be identical to attachment 116789 [details], with the exception of the "(optional)" text having been removed. This is a good thing, but still leaves somewhat unclear "wordage". a) I still like the wording from attachment 117727 [details] better (it makes more grammatical sense to me) but if the "style" of attachment 118448 [details] is to be adopted anyway, I think that "in any of the fields" should be changed to "in one or more of the fields" and "where the field changed to this value" should be "where the value change to".

It's not particularly important to keep the box small; what is important is that it's clear. In this respect, I believe that attachment 117727 [details] wins out over either of the two new ones. I don't think we need the "Where is..." link. For a start, it'll make no sense to people installing Bugzilla for the first time. Gerv

Here's a patch. It works, but it's not well-tested and not ready for review. I'm submitting it in case anyone has time to kill and wants to help testing it. The UI is that of attachment 117727 [details]. The YYYY-MM-DD mentioned on the query page and in the help (queryhelp.cgi and context-sensitive) is not quite accurate. Not only can you also include times, such as YYYY-MM-DD HH:mm, but these fields can accept any format accepted by Date::Parse, i.e. almost any existing format except dd/mm/yyyy. But it may be better to leave this undocumented and not guarantee that all those alternative formats will work in the future. That diff thing, instead of showing a block of code removed and a block of code added, insists in mixing the two because it can match a line in the middle containing a single brace or so. Is there any option to tell it to not synchronise on one line only?

Here it is. That one's ready for review. A comment about the context-sensitive help: I followed the practice of using <br> elements to specify where the context-sensitive help should wrap. However, if your browser window is not very wide and you mouse over the chfieldto field, it wraps in other places as well and it looks terrible.

Comment on attachment 118768 [details] [diff] [review] Patch - take two >Index: queryhelp.cgi >=================================================================== >+<OPTION VALUE="[Bug creation]">[Bug creation]<OPTION VALUE="assigned_to">assigned_to<OPTION VALUE="bug_file_loc">bug_file_loc<OPTION VALUE="bug_severity"> <snip> Please split this onto multiple lines. >Index: Bugzilla/Search.pm >=================================================================== >+ # Processing 'changedin' is for backwards compatibility with existing links >+ # and bookmarks. How about: # "The 'changedin' field is no longer in the UI, but we continue to process it # because it will appear in stored queries and bookmarks. >+ # chfieldfrom and chfieldto should be named something like chfromdate and >+ # chtodate; they have misleading names for backwards compatibility. What's wrong with the names? >+ my $chvalue = $params->param('chfieldvalue') || ''; >+ $chfieldfrom = trim(lc($chfieldfrom)); >+ $chfieldto = trim(lc($chfieldto)); This "lc" is sneaky. I thought you had a bug below because you were doing a direct comparison with the string "now". I tend to name the variables $lcchfieldto to avoid this problem. >+ # The following line deliberately introduces erroneous behavior so >+ # that certain old queries continue to work until corrected; >+ # see bug 37749 comment 26 for details. >+ $chfieldfrom = '0d' if(@chfield && $changedin && $chfieldfrom eq ''); Why do we need to retain this brokenness? > + $chfieldfrom = '' if ($chfieldfrom eq 'now'); > + $chfieldto = '' if ($chfieldto eq 'now'); > + if ($chfieldfrom ne '' || $chfieldto ne '') { If I put "from [ Now ] to [ Now ]" I should get no bugs; but this code will ignore the restriction entirely. >+ # Processing 'changedin' is for backwards compatibility with existing >+ # links and bookmarks. The note about changedin only needs to appear once. But, apart from all the above, you've made changes to the way that queries are constructed, which are very hard to review. Generally, we avoid changing this code unless it's really necessary. What are the functional differences which required these changes? Gerv

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

Something ate the email notification about your comment, Gerv. Lucky I saw it yesterday. >>+ # chfieldfrom and chfieldto should be named something like chfromdate and >>+ # chtodate; they have misleading names for backwards compatibility. > > What's wrong with the names? chfieldfrom means the _from_ date in which the _field_ CHanged. Those fields were used exclusively with chfield. Now they can be used on their own for changes to the bug, not only to specific fields. But, OK, I'll remove that comment, it's pedantic. > >+ # The following line deliberately introduces erroneous behavior so > >+ # that certain old queries continue to work until corrected; > >+ # see bug 37749 comment 26 for details. > >+ $chfieldfrom = '0d' if(@chfield && $changedin && $chfieldfrom eq ''); > > Why do we need to retain this brokenness? There's a link in http://bugzilla.mozilla.org/, "View bugs already reported today". I think I've also seen a predefined query like this somewhere. These have changedin=1 and chfield=[Bug creation]; whoever made them thought the fields were related, but they are not. > But, apart from all the above, you've made changes to the way that queries are > constructed, which are very hard to review. Generally, we avoid changing this > code unless it's really necessary. What are the functional differences which > required these changes? The patch was more work than it seemed at first. Every little change presented the need for another little change, so it's an add-up and I don't remember all small details. But there are two issues which answer your question for the most part: 1) Previously chfieldfrom and chfieldto were used only in combination with chfield. Now you can use them either alone or as before. There is thus a change in the logic. 2) There's an additional bug, I believe unfiled, which I discovered while debugging my patch. If you select [Bug creation] together with any other field in chfield, it ANDs them instead of ORing them. This is because [Bug creation] is using specialchart. In order to correct it I had to process [Bug creation] without the specialchart. (Does anyone really use multiple fields in chfield? Or are we wasting our time making the code unnecessarily complex?)

> There's a link in http://bugzilla.mozilla.org/, "View bugs already reported > today". Then we should fix the link as part of this patch :-) Or, if it's not in the default templates, then add a release note to get people to update their links. > (Does anyone really use multiple fields in chfield? Or are we wasting our time > making the code unnecessarily complex?) That's a good question. I don't think anyone would use multiple fields with "value changed to", but they might want to say "field A and field B both changed between dates X and Y". Perhaps. It's certainly edge-case stuff. Gerv

I've included all Gerv's comments except for one, and I object to another although I did include it. The one I did not include is the "from now to now" case. In fact, it always treats "now" as empty, which means the beginning of time for "from" and the end of time for "to". It may sound strange, but I don't know how to fix this problem. Whatever I do, it will be some additional stupid special-case lines of code. "Now" has no meaning for the "from" field, and I think the behavior isn't bad; it ignores it because it's meaningless. We could get rid of "now" completely, since customarily an empty from/to field means the beginning/end (printing a range of pages is an example). The one I object to is the removal of the deliberate error. If release notes will do, why don't we get rid of "changedin" processing completely? However, I did remove the deliberate error; I don't need much pushing to delete backwards compatibility code :-)

Comment on attachment 120106 [details] [diff] [review] Patch - take three Sorry for the delay. >Index: Bugzilla/Search.pm >=================================================================== >+ # The 'changedin' field is no longer in the UI, but we continue to process >+ # it because it will appear in stored queries and bookmarks. Please add a date to this comment. Otherwise, great. :-) Antonios: I assume you don't have checkin privileges? Gerv

Thanks, Gerv :-) No checkin previleges here.

Fixed. Checking in queryhelp.cgi; /cvsroot/mozilla/webtools/bugzilla/queryhelp.cgi,v <-- queryhelp.cgi new revision: 1.20; previous revision: 1.19 done rlog: /cvsroot/mozilla/webtools/bugzilla/queryhelp.cgi,v:50: missing ';' after 'symbols' rlog aborted 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.17; previous revision: 1.16 done Checking in template/en/default/search/search-help.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/search/search-help.html.tmpl,v <-- search-help.html.tmpl new revision: 1.2; previous revision: 1.1 done Checking in Bugzilla/Search.pm; /cvsroot/mozilla/webtools/bugzilla/Bugzilla/Search.pm,v <-- Search.pm new revision: 1.41; previous revision: 1.40 done Gerv

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

Next time please get approval for your bug *before* you check it in. Thanks.

FYI, the checkin for this bug causes the query page to no longer validate as HTML 4.01 Transitional (the <br> tags between the <dd>s are illegal). See bug 226229.

Reassigning for the sake of statistics, sorry for the spam.

Note bug 232150, a regression created by the patch to this bug.

Another regression caused by this patch: bug 255663 Queries that include both [Bug creation] and anything that causes a join to the attachments table fail.