1231877 - Add a section for Tracking and Project flags to advanced search

Status: NEW

(bugzilla.mozilla.org :: Extensions, enhancement)

Description

[Emma Humphries ☕️🎸🧞‍♀️✨ (she/they) [:emceeaich] (Pacific Time) use needinfo]

Per discussion with dkl and Dylan, requesting a custom page which lets user search for bugs using version tracking flags. Daniel's use case is finding security bugs which would affect ESR releases.

Comment 1

[:glob ✱]

this is already possible with the advanced search page, however i agree it isn't very discoverable.

i think it would be better to add a section to the advanced search page just for the tracking flags rather than creating a separate custom page for that function.  this will be much more flexible and discoverable than a new custom page.

Comment 2

[Emma Humphries ☕️🎸🧞‍♀️✨ (she/they) [:emceeaich] (Pacific Time) use needinfo]

I'd like to have something more actionable for when :glob returns from the end of year revels. Daniel, can you flesh out what a custom search page should support for tracking flags.

Comment 3

[:glob ✱]

(In reply to Emma Humphries [:emceeaich] (GMT-8) from comment #2)
> I'd like to have something more actionable for when :glob returns from the
> end of year revels. Daniel, can you flesh out what a custom search page
> should support for tracking flags.

as per comment 1, a custom search page is not the right fix for this issue.


we should add a 'tracking flags' section to the advanced search page which allows you to select multiple flags and their values.  i picture this being able to add multiple fields with js, with a multi-select control to support multiple "or'd" values.

eg:

** tracking flags

( add [ status-firefox42 v] )

status-firefox43: (remove)
+----------+
| fixed    |
| verified |
| ...      |
+----------+


selecting both fixed and verified from status-firefox43's select would result in:

AND ((cf_status_firefox43 = 'fixed') OR (cf_status_firefox43 = 'verified'))

Comment 4

[Daniel Veditz [:dveditz]]

I have no problems searching for status or blocking flags with the current mechanisms. I mostly use quicksearch but also have some "advanced format" queries I run.

My concern is more of a gut feel that a scheme that requires adding 50 columns to the database every year can't be the best way to do it. The fields distort many parts of the BMO UI -- for example the "change many bugs at once" has gotten extremely unpleasant to use. I suppose that'd be an easy fix to hide the columns behind a javascript button/link like we do on the main bug editing page. Editing a bug is another: because the flags are so cumbersome we've made the choice to disappear most of them even when you do expand the flags. That means I often run into the need to change some status that is gone and inaccessible. I guess not really "often", but regularly enough.

searching wasn't really the problem.

Comment 5

[:glob ✱]

(In reply to Daniel Veditz [:dveditz] from comment #4)
> My concern is more of a gut feel that a scheme that requires adding 50
> columns to the database every year can't be the best way to do it.

fwiw the implementation for tracking flags changed quite some time ago - they are no longer db columns.

> The fields distort many parts of the BMO UI [snip]

agreed - there's a bug on file about the change-many-bugs issue, but there's definitely a lot of UI love needed to make some corners of the ux sane.

> Editing a bug is another: because the flags are so
> cumbersome we've made the choice to disappear most of them even when you do
> expand the flags. That means I often run into the need to change some status
> that is gone and inaccessible. I guess not really "often", but regularly
> enough.

by "gone and inaccessible" are you talking about old values being deactivated when an uplift is performed?

if that's a problem it's worth talking with release management to see if there's value in keeping older values available for longer (although i suspect this may be more of an issue due to the nature of security, and not a general issue).

Comment 6

[Tony Mechelynck [:tonymec]]

(In reply to Byron Jones ‹:glob› from comment #5)
> (In reply to Daniel Veditz [:dveditz] from comment #4)
> > Editing a bug is another: because the flags are so
> > cumbersome we've made the choice to disappear most of them even when you do
> > expand the flags. That means I often run into the need to change some status
> > that is gone and inaccessible. I guess not really "often", but regularly
> > enough.
> 
> by "gone and inaccessible" are you talking about old values being
> deactivated when an uplift is performed?
> 
> if that's a problem it's worth talking with release management to see if
> there's value in keeping older values available for longer (although i
> suspect this may be more of an issue due to the nature of security, and not
> a general issue).

Sometimes I'd want to document that some bug "was already present in SeaMonkey 2.1" or that some other one affected "Firefox 20 but not Firefox 18". Of course the corresponding tracking flags have been disabled by now: they will still appear if they were set while they were active, but they cannot be set anymore. IMHO this disabling is normal: if tracking flags persisted forever as rolldown widgets, their sheer number would soon overwhelm their utility.

What I do when I encounter this situation is I add to the QA whiteboard (if present) or failing that to the (ordinary) whiteboard an entry like [firefox-18-unaffected][firefox-20-affected], or similar.

Comment 7

[Emma Humphries ☕️🎸🧞‍♀️✨ (she/they) [:emceeaich] (Pacific Time) use needinfo]

This touches on searches for other flags, but tracking and release flags are a special case.