Closed Bug 37749 Opened 24 years ago Closed 21 years ago

query for changes to specific field in last n days not working

Categories

(Bugzilla :: Query/Bug List, defect, P2)

2.13
defect

Tracking

()

RESOLVED FIXED
Bugzilla 2.18

People

(Reporter: Brade, Assigned: anthony)

References

(Blocks 1 open bug, )

Details

Attachments

(4 files, 7 obsolete files)

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.
OS: Mac System 8.5 → All
Hardware: Macintosh → 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...

Summary: query for changes in last 2+ days doesn't work (only gives last day) → query for changes in last n days doesn't work
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.
Blocks: 30978
*** 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!
Summary: query for changes in last n days doesn't work → query for changes to specific field in last n days not working
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. ***
Target Milestone: --- → Bugzilla 2.16
Priority: P3 → P2
Mass moving to new product Bugzilla...
Assignee: tara → endico
Component: Bugzilla → Query/Bug List
Product: Webtools → Bugzilla
Version: other → 2.13
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
*** Bug 127775 has been marked as a duplicate of this bug. ***
anyone working on this ?
See also bug 43551.
Blocks: 130835
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.
Attached image Proposed query UI (obsolete) —
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)
Attached image Revised query UI. (obsolete) —
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.
Attached image Revised query UI. (obsolete) —
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.
Attachment #117631 - Attachment is obsolete: true
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
Attached image Revised Query UI - take two. (obsolete) —
New proposal that addresses comments in bug 41, while also dealing with the
"Any" issue.
Attachment #117632 - Attachment is obsolete: true
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.)
Attachment #117718 - Attachment is obsolete: true
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.
Attachment #116789 - Attachment is obsolete: true
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
Attached patch Patch, take one (obsolete) — Splinter Review
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?
Attached patch Patch - take two (obsolete) — Splinter Review
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.
Attachment #118559 - Attachment is obsolete: true
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
Attachment #118768 - Flags: review-
*** 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
Attached patch Patch - take three (obsolete) — Splinter Review
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 :-)
Attachment #118768 - Attachment is obsolete: true
Attachment #120106 - Flags: review?(gerv)
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
Attachment #120106 - Flags: review?(gerv) → review+
Thanks, Gerv :-) No checkin previleges here.
Attachment #120106 - Attachment is obsolete: true
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
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
*** 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.
Flags: approval+
Blocks: 43551
Blocks: 196373
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee: endico → anthony
Status: REOPENED → NEW
Reassigning for the sake of statistics, sorry for the spam.
Status: NEW → RESOLVED
Closed: 21 years ago21 years ago
Resolution: --- → FIXED
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.
QA Contact: matty_is_a_geek → default-qa
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: