We need to validate all queries on the cgi pages. I say this because I just found a bug ("UNCONFIRMEDNEWASSIGNEDREOPENED" appeared as a status), but after I traced it back, I now believe that my stored query actually contains that status. If an error occurred while trying to store that query, I might have been able to work out what the problem was close to the source. We need a reusable parameter checking routine. It should check that all statuses, resolutions, platforms, OSs, severities, etc exist, bug and keyword lists contain only valid elements and separators, all accounts exist, etc. We should regularly call this routine. This means at the start of query.cgi, buglist.cgi and any other cgis that take buglists as parameters. It also means before storing a query. With this in mind, we probably need checksetup.pl to repair busted stored queries. Sometimes we could look for bad parameters and remove them. However if this was the only parameter it would change the behaviour from no bugs to all bugs matching. How we can mark sanitised queries as OK is another matter too. Perhaps we should just let them break and expect people to fix them.

There is a comment in the code roughly along the lines that 'we shouldn't break the query page', and I agree. It would be serious if your default query was broken. So here's my suggestion here: If you try to store a broken default or named query, it should fail. If you load a broken query on the query, bug list or bulk change page, there should be one or more warnings at the top of the page: 'BLAH' is not a recognised status and was ignored. 'T' is not a recognised product and was ignored. etc.

One thing that needs to be let through is valid sort orders that normally don't appear on the query page. This is necessary to be able to store queries with these sort orders. See also bug #89829. Invalid sort orders should still fail of course.

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.

These bugs appear to be abandoned. Retargeting to 2.20

I actually haven't ever seen the need for this, at least not on any wide scale that would be required to justify the code complexity.

(In reply to comment #6) > I actually haven't ever seen the need for this, at least not on any wide scale > that would be required to justify the code complexity. I agree -> WONTFIX.