87966 - Validate saved queries on use, and display messages about invalid parts

Status: RESOLVED WONTFIX

(Bugzilla :: Query/Bug List, enhancement, P5)

Description

[Matthew Tuck [:CodeMachine]]

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.

Comment 1

[Matthew Tuck [:CodeMachine]]

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.

Comment 2

[Matthew Tuck [:CodeMachine]]

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.

Comment 3

[Christopher Aillon (sabbatical, not receiving bugmail)]

Mass moving to new product Bugzilla...

Comment 4

[Dave Miller [:justdave]]

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.

Comment 5

[Joel Peshkin]

These bugs appear to be abandoned.  Retargeting to 2.20

Comment 6

[Max Kanat-Alexander]

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.

Comment 7

[Frédéric Buclin]

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