Allow specifying arbitrary columns in bug listings

[Christopher Armstrong]

Colin Watson wants to see the reporter of bugs in bug columns (#6708). I don't care about reporters, but I often want to see the assignee or the milestone as columns. This perhaps means that the best thing to do would be to allow specifying the columns to display in the advanced search form. (A series of checkboxes? Maybe something else that can represent ordering?)

See also:
 - bug 766960

[Joey Stanford (joey)]

I've had additional requests for this functionality so I'll talk with Bjorn about this to see if it's possible.

[Joey Stanford (joey)]

upgrading from wishlist to low based on feedback received

[Diogo Matsubara (matsubara)]

Taggeed this one with oem-services as bug 297617 which I dupe against this one is tagged with it.

[Robbie Williamson (robbiew)]

IMO, this is a basic feature (even bugzilla has it) that the platform team really needs. Seeing it as a "low" priority doesn't give me much hope that we will see it implemented anytime soon...but I could be wrong.

[James Ferguson (jamesf)]

Have to echo Robbie Williamson on this. I can't believe this is marked medium. It's very basic functionality.

As it is, I have a greasemonkey script which works by pulling up each bug in turn and trawling through it to get the assignee. Very inefficient, but essential to make bug search useful.

[Eleanor Berger (intellectronica)]

I'd like to dispute the current status of the bug and suggest that it's actually WONTFIX, or at least INCOMPLETE. I very firmly believe that adding customization makes the program harder to learn and use, and that it's really just a cop-out from the real challenge, which is providing an interface that works well for most users without customization. If we ever plan to implement this, we will first have to have a really good plan for the feature. I don't think that in its current state it's ready to be worked on.

Note that for very specialised cases, it is now possible to use the Launchpad REST API, perhaps in conjunction with greasmonkey, to create all sorts of custom views.

[Deryck Hodge (deryck)]

I do think this is basic bug tracker search functionality, and we could do even more to make search better in Launchpad bugs, as other bugs confirm.

Unfortunately, the reality is that we won't get to this anytime soon. There are already 3-4 stories waiting their turn, so the chance of a search story in the next 6 months is not likely.

[James Ferguson (jamesf)]

I would be surprised if my usage is unusual, and I'm not exaggerating when I say I feel like I'm working with one hand tied behind my back when querying bugs in Launchpad compared to other bug tracking systems I've used. I spend far too much time looking at a bug query and opening every bug in the list in separate tabs just to go and look at one field in each.

The simplicity of the current search makes /using/ it very complicated. I could come up with any number of real everyday use-cases...

I agree it has to be well planned. The whole advanced search could do with a revamp. My feeling is that task should rise to the top of the list sooner rather than later.

[Bryce Harrington (bryce)]

On Fri, Jan 29, 2010 at 08:48:56PM -0000, James Ferguson wrote:
> I would be surprised if my usage is unusual, and I'm not exaggerating
> when I say I feel like I'm working with one hand tied behind my back
> when querying bugs in Launchpad compared to other bug tracking systems

I know how you feel. But it's true the launchpadlib api gives a huge
amount of power to us to make our own search tools, and a lot of us have
been doing exactly that.

You can see examples of a few of the custom search pages I've done for
my own needs here:

  http://bryceharrington.org/X/Reports/

Since I'm doing this with python scripts ('arsenal') I can get pretty
indulgent as to what I include. Like I have one report which shows bugs
only from people with karma > 10,000.

What we're starting to see is as these side-efforts produce interesting
reports, the Launchpad team uses them as mockups for their own work.
For example, you can find a "bugs with patches" report at the above
link; the launchpad team thought it looked cool and are making an even
cooler implementation within launchpad itself.

The QA team also has been accumulating specialized reports. The QA and
desktop teams are also working on a GUI tool called bughugger with much
more powerful searching capabilities called bughugger. See a screenshot
here:

  http://www.murraytwins.com/blog/?p=60

bughugger is still pretty early in development, and extremely open to
new ideas.

So why wait 6+ months for some abstraction to launchpad - look into the
above projects that use launchpadlib and help add your own ideas, or
code up your own report tool yourself. You'll be able to make a custom
solution that addresses your own needs, and if you come up with
something which really is generally useful, it'll give the launchpad
team a solid proof of concept to work from.

[Martin Pool (mbp)]

I think the difference is bug 766960 (and it may have some friends) is
that they are saying it would be nice if the view for say inprogress
bugs was oriented towards things you probably want to know about those
bugs (like who they're assigned to) which is different to total
customization. In some ways easier; in others less powerful. Either
could be good, or both.

Martin