Bug 453661 - per list bug list column headers can't be cleared
per list bug list column headers can't be cleared
Status: CLOSED CURRENTRELEASE
Product: Bugzilla
Classification: Community
Component: Query/Bug List (Show other bugs)
3.2
All Linux
low Severity high (vote)
: ---
: ---
Assigned To: David Lawrence
:
Depends On: 453658
Blocks:
  Show dependency treegraph
 
Reported: 2008-07-01 15:15 EDT by Doug Ledford
Modified: 2013-06-24 00:08 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-08-08 15:24:42 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Patch to clear columns for saved search back to default values (v1) (863 bytes, patch)
2008-07-02 17:40 EDT, David Lawrence
nelhawar: review+
Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
Mozilla Foundation 443479 None None None Never

  None (edit)
Description Doug Ledford 2008-07-01 15:15:32 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.
Comment 1 Doug Ledford 2008-07-01 15:17:07 EDT
Oh, and defaulting to global instead of list specific column changes would seem
to make more sense to me as well.
Comment 2 Doug Ledford 2008-07-01 15:45:39 EDT
Or better yet, if a list specific setting exists, then default to list specific
changes, else default to global changes.
Comment 3 David Lawrence 2008-07-02 17:38:04 EDT
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.

Dave
Comment 4 David Lawrence 2008-07-02 17:40:39 EDT
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.

Thanks
Dave
Comment 5 Noura El hawary 2008-07-02 21:29:29 EDT
Comment on attachment 310857 [details]
Patch to clear columns for saved search back to default values (v1)

Looks good to me Dave.

Noura
Comment 6 David Lawrence 2008-07-03 12:45:06 EDT
Doug, can you verify that this fixes the issue for you on our internal test
site, https://bz-web2-test.devel.redhat.com?

Thanks
Dave
Comment 7 David Lawrence 2008-07-03 15:35:26 EDT
Filed upstream:

https://bugzilla.mozilla.org/show_bug.cgi?id=443479
Comment 8 Doug Ledford 2008-07-04 11:57:30 EDT
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
selections.

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.
Comment 9 Noura El hawary 2008-07-07 02:52:57 EDT
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.

Noura
Comment 10 David Lawrence 2008-07-07 10:52:09 EDT
(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
Bugzilla.


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

Comment 11 David Lawrence 2008-07-16 22:09:14 EDT
Removing from blocker
Comment 12 David Lawrence 2008-08-08 14:49:20 EDT
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?

Thanks
Dave
Comment 13 Doug Ledford 2008-08-08 14:54:49 EDT
It makes sense and should be fine.
Comment 14 David Lawrence 2008-08-08 15:24:42 EDT
Thanks!

Dave

Note You need to log in before you can comment on or make changes to this bug.