226751 - Ability to configure displayed fields in buglist long-list format

Status: NEW

(Bugzilla :: Query/Bug List, enhancement)

Description

[Linda S. Aramil]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4a) Gecko/20030401
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4a) Gecko/20030401

Sorry if this is a dup.  I searched the bugs db and didn't find this one.  

We're currently running Bugzilla version 2.14.1.  

It would be nice if the fields to be displayed in the buglist long format were
configurable, similar to the buglist page.  Depending upon our project managers,
the fields desired to be displayed in the Long Format vary;  therefore, it would
be nice if it were configurable so each mgr could determine which fields to display.

Reproducible: Always

Steps to Reproduce:
1. Go to the Query page and enter information that will produce a list of bugs.
2. Click on the Long Format option.
3. Notice that some fields are not displayed in the Long Format (cc,
dependencies, blocks, etc)

Actual Results:  
We noticed that some desired fields are not displaying in the buglist Long Format.

Expected Results:  
It would be nice if the user could choose which fields to display in the buglist
"Long Format", similar to the buglist columns.

Comment 1

[Robert Mohr]

WFM.  Reporter, can you make a testcase URL and put it in the URL field?

Comment 2

[Robert Mohr]

Whoops, I did some searching and then came back to the wrong bug to comment. 
Nevermind that last comment and sorry for bugspam.

Comment 3

[Peter Bittner]

(In reply to comment #0)
> It would be nice if the fields to be displayed in the buglist long format
> were configurable, similar to the buglist page.

I have a suggestion that goes (not quite) into the same direction. First, why do
I come here, what ist the problem:

The "Format For Printing" page (which is technically the same as the "Long
Format" bug listing) is ** too wide ** if you have

 - too long reporter names (e-mail addresses do not split up in a column)
 - too long assignee names, too long QA person names (same problem as above)
 - too long product names (if it is all, say, in a single word)
 - etc.

Printing the page results in cutted off content on the right end side.

I have done a (kind of) redesign of the page, reordering the fields in the "Full
Text Call Listing". It looks like this, is rather logical to read for the end
user and (generally) works perfect for printing:

 [Bug#: _____________ ]   [Product: ____________ ]   [Opened: _____________ ]
 [Severity: _________ ]   [Component: __________ ]   [Reported By: ________ ]
 [Priority: _________ ]   [Version: ____________ ]   [Assigned To: ________ ]
 [Resolution: _______ ]   [Hardware: ___________ ]   [QA Contact: (optional)]
 [Status: ___________ ]   [OS: _________________ ]   [Target Milestone:(opt)]
 [URL: ____________________________________________________________________ ]
 [Summary: ________________________________________________________________ ]
 [Description:
 [ ...blah-blah-blah....

The key points of this layout:

 - only 3 colums
   (Makes it easier for the page to adapt to narrow windows/screens/pages)

 - columns describe familiar characteristics
   (Column 1: Bug related stuff; Column 2: Product related; Column 3:
    Stuff related to persons and dates - "when did who what?")

 - data expected to be rather long gets a row of its own (e.g. URL, Summary)

(NB: In the above sketch I have tried to visualize which colums span over the
whole page width by using the [__] notation.) 

I think this would be a sensible default layout for the "Full Text Call Listing"
which usually allows printing and viewing the page without problems.

Giving the possibility to choose what fields to display would be the next great
enhencement. (Hope this bug is read by someone working on this code; by the way,
the file affected is: template/en/default/bug/show-multiple.html.tmpl)

Comment 4

[Dave Miller [:justdave]]

Reassigning bugs that I'm not actively working on to the default component owner
in order to try to make some sanity out of my personal buglist.  This doesn't
mean the bug isn't being dealt with, just that I'm not the one doing it.  If you
are dealing with this bug, please assign it to yourself.

Comment 5

[A. Karl Kornel]

Suggest confirming.

I really like this, with some modifications: Move Status above Resolution, and
move Status/Resolution above Severity/Priority.  Add keywords & status
whiteboard on their own lines above the URL field.

Comment 6

[Max Kanat-Alexander]

Can this not already be done with includefield and excludefield CGI parameters?
If it's not a DUPLICATE, and it's not WFM, then it should be confirmed. (That's
what we do with all enhancement requests.)