Red Hat Bugzilla – Bug 453661
per list bug list column headers can't be cleared
Last modified: 2013-06-24 00:08:06 EDT
Bring up any saved query (for example, my Fedora Bugs search)
From that query screen, select Change Columns
The Change Column form defaults to setting the columns for the list that you
were displaying when you selected Change Columns only as opposed to changing the
columns settings globally
If you neglect to unset this option, then your columns on that list will have an
override that can't be removed (at least I can't find anything that would reset
the list specific column changes)
On experimentation, the Reset to Redhat Bugzilla Default does the trick, but
that button sounds more like it would reset the column definitions globally than
just on the list in question...in the event of a list with a custom column
definition saved on it, it might be more obvious if you had a "Clear list
specific column definition" button, at least then people wouldn't be concerned
that hitting the button would clear out their column definitions globally.
Oh, and defaulting to global instead of list specific column changes would seem
to make more sense to me as well.
Or better yet, if a list specific setting exists, then default to list specific
changes, else default to global changes.
I have verified that it is not possible to clear the columns for a stored search
and restore them to the defaults which is a bug IMO. I have created a patch that
solves this in my testing. Will attach for review by bugzilla team.
Created attachment 310857 [details]
Patch to clear columns for saved search back to default values (v1)
Patch allows clearing of column list for a saved search and resets back to the
default columns for that search.
Noura, please review.
Comment on attachment 310857 [details]
Patch to clear columns for saved search back to default values (v1)
Looks good to me Dave.
Doug, can you verify that this fixes the issue for you on our internal test
Now it's more broken than it was before :-(
Before, I could clear out a column setting that applied to a single bug report
only by clicking on the "Reset to Red Hat Bugzilla Default" button. What this
bug report was about was that the "Reset to Red Hat Bugzilla Default" button
would only reset your column list to the Red Hat default *if* and only if you
didn't have a new default column set changed. So, the button was somewhat
ambiguous and tends to make a person think they might loose more than just the
settings for the list they are looking at.
Now, even when I click that button, it never resets the specific list's column
The easiest way to test this is to have to saved searches. Bring one up and
change its column settings, but make sure you uncheck the "Save this column list
only for search <blah>" box before you save it. Now both of your searches
should use the custom list. Then go into either list and change its columns
again to something else, and this time leave the "Save this column list only for
search <blah>" box checked. Now, you should have one list using the first
column settings and one using the second. Then go into the change columns for
the list you individually modified and hit the reset to bugzilla default, and it
won't reset it back to your global list any more.
So, long story short, the old set actually worked, it was just ambiguous and
misleading in its button labelling. The new version no longer works.
I did more testing with and without the patch, so basically the current behavior
on partner-bugzilla without the patch is,
1- if the user changed a saved search columns without checking the "Save this
column list only for search '$SOMETHING'" , then all the searches wether saved
or not will have those changed columns in the output except for the ones who
have their own saved customized column list.
2- if the user change a saved search columns with checking the "Save this column
list only for search '$SOMETHING'", then if they try to set that search back to
the default global column list it will not work.
if the above cases are the correct and expected behavior then the original code
of 3.2 is fine and the previously attached patch is not needed.
(In reply to comment #9)
> I did more testing with and without the patch, so basically the current behavior
> on partner-bugzilla without the patch is,
> 1- if the user changed a saved search columns without checking the "Save this
> column list only for search '$SOMETHING'" , then all the searches wether saved
> or not will have those changed columns in the output except for the ones who
> have their own saved customized column list.
Right, the saved searches that do not have a column list in the URL that is
saved in the namedqueries table, it falls back to whatever the COLUMNLIST cookie
is that is set in the users browser or if not that then the default list for
Bugzilla. So resetting to the default columns in colchange.cgi without the saved
search checkbox checked, it resets the COLUMNLIST cookie to the defaults for
> 2- if the user change a saved search columns with checking the "Save this column
> list only for search '$SOMETHING'", then if they try to set that search back to
> the default global column list it will not work.
This is where I believe is a problem. A user currently cannot reset back to the
default column list for a specific saved search. Currently you have to manually
set the checkboxes for each column back to the defaults if you know what they
are and then resave. Currently if you click the reset to defaults button it
resets the COLUMNLIST cookie which will affect all saved searches (or non-saved)
that do not have their own column list stored already. So it is misleading IMO
that having the saved search checkbox checked on colchange.cgi and then clicking
the reset to defaults button does nothing to the saved search.
> if the above cases are the correct and expected behavior then the original code
> of 3.2 is fine and the previously attached patch is not needed.
Removing from blocker
FWIW, the patch I attached which I originally thought was addressing this bug has been accepted upstream and is also in our version to be made available for the next update.
Essentially it does what I first described that if you run a stored query, click on Change Columns and edit the columns that are displayed, it should only edit the columns displayed for that stored query. If you uncheck the "For this stored query" checkbox though it will edit the columns globally and not for the stored query specifically.
On the other side if you leave the stored query checkbox checked and click the "Reset to defaults" button it will clear the columns for that stored query only and the next time you run it, it will show the columns that you have set globally.
Does this make sense and also does this still not address your original concern?
It makes sense and should be fine.