buglist.cgi can already do CSV output by adding &format=csv to the URL. There needs to be a UI on the query page for selecting this.

ok, maybe it can't do it already... I could swear I saw that before. Well, it needs it, anyhow. :-) So we need a CSV output format for buglist.cgi :) CCing Gerv because he just did this for reports.cgi

This should be pretty trivial - I'm sure I can knock this up. Is this a nice-to-have, or do you have a business need? Gerv

See the dependencies. 'nuff said :)

.

Here's a v1. But I need to better understand the need here. Is there a need to access buglists in a machine-readable form, or are humans going to want to extract buglists themselves to import into spreadsheets? If it's just machines, this template needs no UI. If it's humans, it needs some of some sort. Assuming humans want this, if someone requests CSV, do they expect all the columns, or just the ones in the HTML version (RDF currently works this way)? A human or machine can override the columnlist with &columns=all, or some such syntax - should that be built into the accessor link? I've avoided adding UI to query.cgi because that page is already pretty complex, and people want HTML 99.99% of the time. Gerv

It'll be humans, for the purpose of importing the data into Excel. They want to be able to choose on the query page, just like you do on the reports page. Also on their list is a way to specify which columns get included from the UI, but that's a different bug. (My personal preference would be buttons on the form just like the "add another boolean chart" but they load additional controls such as column list and sort order and so forth, but we can discuss that on that other bug :)

> It'll be humans, for the purpose of importing the data into Excel. They want to > be able to choose on the query page, just like you do on the reports page. I think that the current model is a better one - you choose your query and display the list as HTML, refine the columns, get it right, and then click "CSV" to get a CSV version of what you've got at the moment. I really think that adding yet more controls to query.cgi is a bad route to go down. Of course, it could be a simple local customisation :-) > Also on their list is a way to specify which columns get included from the UI, > but that's a different bug. (My personal preference would be buttons on the > form just like the "add another boolean chart" but they load additional > controls such as column list and sort order and so forth, but we can discuss > that on that other bug :) Which bug is that? And what's wrong with the current column selection controls? Can we give them a XUL version to shut them up? :-) Gerv

OK, a "display as CSV" or whatever link on the buglist page itself works for me. (I hadn't actually looked at what you did here yet) The other bug for the column choice UI is bug 105110.

Comment on attachment 104680 [details] [diff] [review] Patch v.1 r= justdave It works, and it even looks good in Excel :-)

IF you're going to add choices, should the rdf output be added? Even better, should we somehow auto-detect the availbale formats to display in the list, by looking at the avaiable templates? :) (No, I'm not serious about that one, unless you happen to have a patch for doing so...)

hmmm.... if we have a way to set the Content-Disposition header here, the CSV type should be sent out with Content-Disposition: attachment instead of inline... so it forces a file-save dialog. It's pretty useless in a browser window :-)

> IF you're going to add choices, should the rdf output be added? No, IMO. That's definitely machine-readable only; the people using that will be writing Bugzilla clients, and will read the documentation to find out that it's available. > Even better, should we somehow auto-detect the availbale formats to display in > the list, by looking at the avaiable templates? :) (No, I'm not serious about > that one, unless you happen to have a patch for doing so...) :-) I'd say we need the freedom to pick the formats we have appearing or not; also, different formats often require different UIs (see report.cgi's two search templates for examples of this.) > if we have a way to set the Content-Disposition header here, the CSV type should > be sent out with Content-Disposition: attachment instead of inline... so it > forces a file-save dialog. It's pretty useless in a browser window :-) Er... File | Save As seems to work fine for me :-) It's good to preview what you are getting, IMO. People expect text types to be displayed in the browser. Gerv

despite the other comments here, my second-review still stands, feel free to check this in and resolve the bug :-)

Fixed. Checking in template/en/default/list/list.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/list/list.html.tmpl,v <-- list.html.tmpl new revision: 1.9; previous revision: 1.8 done RCS file: /cvsroot/mozilla/webtools/bugzilla/template/en/default/list/list.csv.tmpl,v done Checking in template/en/default/list/list.csv.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/list/list.csv.tmpl,v <-- list.csv.tmpl initial revision: 1.1 done Gerv