61447 - Column width control in bug lists

Status: RESOLVED WONTFIX

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

Description

[Eric Hanson]

I was looking at the set columns page for bugzilla ( where you choose which
columns to display after you query a bug: buglist.cgi ) and was wondering if
each checkbox could also have a text field next to it that would contain a value
that would determine the width (in characters) of the column on the
report.cgi page.  My company has several severities that begin with the
same three letters so I have to hand edit the CGI's to change the column
length, it was actually pretty easy and I was impressed by the quality of code. 
I only had to change the variables in one place, where the cgi pulls the data
out of the database, I just change the values so more info would be pulled out.  
I was thinking that bugzilla could have an additional column that would
deteremine width ( in characters ), and it would query that column, to make it
quick it could probably be stored in versioncache (just some thoughts, I haven't
looked at it myself, if I do, I will let you know ).

Comment 1

[Eric Hanson]

I have been thinking about how this might be done, and since the actual data
regarding which columns to show is kept in a cookie (from what I can tell), then
the column width could be stored there too, with resonable defaults if no
cookie.  From what I know of cookies they are somewhat limited in space, and
didn't know if there was any room for more data.  I would hate to implement it
and then find out that the solution doesn't work.

Comment 2

[Eric Hanson]

Attachment: this is a diffpatch of three different files (colchange, buglist, globals)

Comment 3

[Eric Hanson]

I have actually implemented the proposed enhancement.  I simply made another
cookie, I didn't want to mess with the existing ones, and added my information
into it.  I had to modify globals.pl to include my default values, I changed
buglist.cgi so that it would look at the cookie to figure out how much text to
pull from the database, and I changed colchange to create the cookie and do some
basic UI stuff and to do minor error checking on my cookie.  
A note about the patch file.  Not all of the changes in teh file are pertanint
to bugzilla, some are cosmetic changes my company did (change the OS label to
POP, etc.) please ignore these.
Also I went through and tried to helpfully comment colchange.cgi since I felt I
understood it pretty well now.
Hope this helps.  I am thinking of posting the changed files in thier entirety
in the newsgroup, let me know if the patch file is good.
Eric Hanson

Comment 4

[Eric Hanson]

adding keywords patch, review

Comment 5

[Dave Miller [:justdave]]

Why are you adding 2.12 and patch?  This bug is already fixed.  Unless it was 
marked fixed in error.  If that's the case, please reopen it.  A bug is not fixed 
until it's checked into the tree.

Comment 6

[Eric Hanson]

Because I didn't think it was in the tree yet.  I thought I had marked it FIXED
once I provided the patch (since I had created the patch I assumed that  would
mean the bug was fixed).  Sorry about the email, I didn't know if it was checked
into the tree or not, that would be a nice whiteboard status, or if CLOSED or
RESOLVED was used to indicate whether the patch is now in the bugzilla tree.

Comment 7

[Dave Miller [:justdave]]

"FIXED" means it's in the Bugzilla tree.  By marking it "FIXED", you effectively 
got it ignored, so no one saw it to be able to check it in.  Reopening...

Comment 8

[Eric Hanson]

Thanks, sorry about the confusion, I didn't read the definitions for the
Status.  Should I ever change the status or resolution, even if I provide a
patch?

Comment 9

[Dave Miller [:justdave]]

Removing 2.12 nomination.  As the reporter noted, the patch does include a couple 
of his company's site-specific changes as well, and the patch will need to be 
massaged a bit before it can be applied to cvs.  I like the idea a lot though, I 
think it'd definitely be something nice to have, but we're too close to releasing 
2.12 at this point to fit it in between now and then.

Comment 10

[Dave Miller [:justdave]]

yeah, no need to touch the status unless you think it wasn't resolved correctly, 
then you can reopen it.  If you're working on a patch for it, you can feel free 
to reassign the bug to yourself so we know you're working on it.  But it would 
probably be a good idea to CC someone with checkin privs (like the original 
owner).  Adding the "patch" keyword is usually good enough to get our attention 
when you post a patch (assuming the bug is still open so it shows up on our 
queries :)

Comment 11

[Eric Hanson]

Attachment: New patch with offending (site specific) code removed. Should play nicely with a bugzilla 2.10

Comment 12

[Eric Hanson]

The new patch is the same as the previous, except I removed a chunk of code that
did some specific relabling of the 'os' field.  The chunk was unfortuneatly
stuck in a part of the patch where it couldn't be deleted easily.  This should
work.  Good luck with 2.12.

Comment 13

[Eric Hanson]

I was curious, should I reassign this to myself (since I gave the patch) or does
someone have to have tree checkin privilages to accept bugs?  I realize this
isn't high priority since it won't be resolved until 2.16.  Thanks.

Comment 14

[Dave Miller [:justdave]]

Normally, if you're in the process of working on a patch for it, and don't want 
someone else to duplicate the effort, you would assign the bug to yourself while 
you're working on it.  Once the patch was completed and uploaded, you would 
reassign the bug to someone with checkin privs, or at least CC someone with 
checkin privs, so it can get reviewed and checked in.

With the way we are organized now, usually just adding a "patch" keyword will get 
the attention of the right people once the milestone it's set for is in progress.

Comment 15

[Eric Hanson]

Who changes the target milestone on this guy?  I am guessing it will be 2.16
since 2.14 will be security fixes.  Should I change it or wait for someone from
mozilla.org to?

Comment 16

[Eric Hanson]

Since I submitted and fixed this I thought I would assign it to myself :)

Comment 17

[Dave Miller [:justdave]]

*** Bug 41347 has been marked as a duplicate of this bug. ***

Comment 18

[Dave Miller [:justdave]]

*** Bug 83137 has been marked as a duplicate of this bug. ***

Comment 19

[Andreas Franke (gone)]

-> Bugzilla product, Buglist component.

Comment 20

[timeless]

*** Bug 86937 has been marked as a duplicate of this bug. ***

Comment 21

[Andreas Franke (gone)]

Eric, does the patch still work with 2.14 / 2.15? If not, can you attach a new
patch?

Comment 22

[Gervase Markham [:gerv]]

*** Bug 33307 has been marked as a duplicate of this bug. ***

Comment 23

[Gervase Markham [:gerv]]

Without a patch to 2.15, this isn't going to make the 2.16 train.

Gerv

Comment 24

[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 25

[Eric Hanson]

  I have been away for a while.  I do not have access to Linux or Bugzilla right 
now and unfortuneatly may not for some time.  If someone could tell me how to 
allow someone to take over this bug or put it up for grabs, I would appreciate 
it.

Comment 26

[Dave Miller [:justdave]]

-> default component owner, per current owner

Comment 27

[Joel Peshkin]

Attachment: Updated patch works with templates

Preliminary patch.  Someone -- please suggest a less ugly way to format the
colchange.cgi UI.

Comment 28

[Joel Peshkin]

may as well adopt this

Comment 29

[Joel Peshkin]

Attachment: Patch - no longer ugly

Comment 30

[Gervase Markham [:gerv]]

I'm not convinced that this patch is necessary. It may have been when the bug
was filed, but templatisation has made it obsolete.

If you look at template/en/default/list/table.html.tmpl , you'll see that the
abbreviated width of columns is defined there (the "maxlength" field of the
hash.) If this user's company has several severities with the same first three
letters, then changing the "3" to a "6" in the severity entry will cause
severities to be abbreviated at 6 letters. Problem solved.

Bearing in mind the above, is there now a need for additional code?

Gerv

Comment 31

[Joel Peshkin]

I went through the option of tweaking templates with the users that requested
this.  The problem is that they frequently need to pull data into special lists
as almost a one-of report.

Comment 32

[Gervase Markham [:gerv]]

Joel: you have users who want this? Or do you mean the filers of this bug report?

If the situation is that "My company has several severities that begin with the
same three letters", then editing the widths in the template is an appropriate
fix. Are you saying that people want different widths at different times? 

Gerv

Comment 33

[Joel Peshkin]

Yes.  My users want differrent widths at differrent times.

Comment 34

[Gervase Markham [:gerv]]

Why? Can you give an example?

The reason I'm persisting with this is that there's no really good way to do the
UI for this - so it has to be a well-wanted and useful feature for it to be
worth committing, and living with the UI nastiness and code hackiness.

Gerv

Comment 35

[Jouni Heikniemi]

Comment on attachment 101252 [details] [diff] [review]
Patch - no longer ugly

Bitrot strikes back!

Comment 36

[Dave Miller [:justdave]]

Bugzilla 2.20 feature set is now frozen as of 15 Sept 2004.  Anything flagged
enhancement that hasn't already landed is being pushed out.  If this bug is
otherwise ready to land, we'll handle it on a case-by-case basis, please set the
blocking2.20 flag to '?' if you think it qualifies.

Comment 37

[Gervase Markham [:gerv]]

Now that we have CSV output, which allows the automated extraction of buglists
and the feeding of them into any reporting tool under the sun, can we WONTFIX this?

Or, if not, it should be implemented as JavaScript/DOM draggable dividers
between columns. :-)

Gerv

Comment 38

[Joel Peshkin]

More likely, it will wind up as some sort of format control for buglists.  That
will also help where people want to see the date a column was changed (like a
status, assignee, or status whiteboard).

Comment 39

[Onno Garms]

(In reply to comment #37)
> Now that we have CSV output, which allows the automated extraction of buglists
> and the feeding of them into any reporting tool under the sun, can we WONTFIX
this?

Feeding into in external tool is an additional step for the user.
So I would really like an internal way to control column width.

> Or, if not, it should be implemented as JavaScript/DOM draggable dividers
> between columns. :-)

That sounds great.

Unfortunately I'm to busy to do any implementation myself. Sorry.

Comment 40

[Shane H. W. Travis]

*** Bug 279153 has been marked as a duplicate of this bug. ***

Comment 41

[benc]

Gerv: I think people will want to change the width, the same way people change
the widths alot in Excell columns.

I also think that what people want, but are not saying, is a setting where the
column is automatically the width of the longest value in that column.

Comment 42

[Gervase Markham [:gerv]]

benc: such a setting would be rather tricky to implement. You'd need some
advanced JS which ran when the page finished loading and set the column sizes
according to how the text was displayed - assuming you could even find out if
the text in a particular cell was wrapped and, if so, by how much.

Gerv

Comment 43

[Frédéric Buclin]

The trunk is now frozen to prepare Bugzilla 2.22. Only bug fixes are accepted, no enhancement bugs. As this bug has a pretty low activity (especially from the assignee), it's retargetted to ---. If you want to work on it and you think you can have it fixed for 2.24, please retarget it accordingly (to 2.24).

Comment 44

[Frédéric Buclin]

We are freezing the code for 3.0 in two weeks and we don't expect this bug to be fixed on time.

Comment 45

[Anna-Lena Costermans]

In order to effectively use Bugzilla at my company we would like to change the column width in the Bug list. Since the Search-function - and the bug list function in particular - is very important when using Bugzilla, it seems like an important function. We have made a two-layer component structure (something like A - bc, A - de, B - fg, B - hi and so forth), which makes it important to see more of the component-names.

Comment 46

[James Cigler]

This has been one of the few negative aspects about bugzilla that I've received comments about since implementing at our company.  Several of the character limits (like 3 for Platform) are *entirely* too short.  The "ASSI" status (or rather its phonetic pronunciation) has become somewhat of a running inside joke.

The simplest suggestion so far, by the original reporter, of having a text field to define the field length would go a very long way on improving this.  Obviously, some fancy logic for determining the widest possible column width based on browser window size and num of columns would be ideal, but not *required*.

Comment 47

[Gervase Markham [:gerv]]

You know you can change the widths by editing a template, right?
template/en/default/list.table.html.tmpl

Gerv

Comment 48

[James Cigler]

(In reply to comment #47)
> You know you can change the widths by editing a template, right?
> template/en/default/list.table.html.tmpl
I do now, thanks!  I figured editing some file would work, but it being a template is much easier.
I seem to have overlooked this in the documentation as well.

Comment 52

[Asa Dotzler [:asa]]

Can we move the truncation out of the template and let the full HTML hit the page, then use CSS to elide properly? That way it could more easily modifiable and we'd have something that wasn't sending out awfully incomplete HTML to the page so extensions could do more when css wasn't enough.

Comment 53

[Gervase Markham [:gerv]]

Asa: nice idea, but it's not this bug. Please file a new one ("Use CSS for truncation in buglists instead of doing it server-side") and CC me.

Gerv

Comment 54

[:glob ✱]

given it's possible to edit the template to change the widths, bug lists are exposed via our APIs, and bug 964404, there's nothing more to do here.