82878 - It would be cool if queries could produce RSS 1.0...

Status: RESOLVED FIXED

(Bugzilla :: Query/Bug List, enhancement)

Description

[Mark Nottingham]

so that people could put a bugzilla query in their RSS aggregator and keep an
eye on bugs they're interested in...

Comment 1

[Dave Miller [:justdave]]

What is RSS?  Never heard of it.

Comment 2

[xyzzy]

Assuming bug 48707 is implemented, here are some ideas:

1) This could be done directly with a flag in a simlar fashion
2) An XSLT stylesheet for RSS output could be added to that bug
3) Use another indirect solution (XML to RSS via Transformiix under Bugzilla, 
e.g.)

I personally feel that #2 is the best solution.  Marking dependency on 48707, 
please change if you go a different route...

Comment 3

[xyzzy]

Dave,

Check out http://groups.yahoo.com/group/rss-dev/files/specification.html

Comment 4

[xyzzy]

Very similar to bug 49225, except we want RSS instead of HTML.

Comment 5

[Matthew Tuck [:CodeMachine]]

Moving to new Bugzilla product ...

Comment 6

[Gervase Markham [:gerv]]

Bugzilla can produce any format of results you like if someone writes the
template - it already does RDF. I'd be worried about this, though, because "keep an
eye on bugs they're interested in" sounds like "Spam the server every ten
minutes with the same query", which would be Really Bad.

Gerv

Comment 7

[Henri Sivonen (:hsivonen)]

I think it would be more like running the same query only every 30 minutes. :-)

Perhaps a Bugzilla proxy could solve the problem.

Comment 8

[Ben Meadowcroft]

Most good RSS implement ETAG checking and/or last modified date algorithms to do
conditional gets. If bugzilla can cope provides either a last modified header or
an ETAG then the load shouldn't be too bad. In addition most RSS readers poll
every hourly by default.

Comment 9

[Walter Hoehn]

Attachment: Bug List RSS template

I have attached a template that formats the Bug List in RSS 0.91. Comments?

Comment 10

[Tobias Burnus]

Some nits (sorry no full review):

	[% numString = "Zero Bugs Found."%]
this should be
        [% numString = terms.zeroSearchResults %]

	[% numString = "One bug found."%]
	[% numString = "$bugs.size bugs found." %]

Replace bug and bugs by [% terms.bug %] and [% terms.bugs %]
and include
  [% PROCESS global/variables.none.tmpl %]
at the beginning.

Nit: 
  [% template_version = "[e-mail]" %]
should be in the first line.

Comment 11

[Walter Hoehn]

Attachment: Bug List RSS template (update)

Generally updated to work with HEAD (was previously based on 2.16).
Implemented suggestions by [e-mail] .
Switched to correct URL filter.

Comment 12

[erik johansson]

I would like to have this but for "my votes" instead. To tell my friend what
bugs to vote for.

Comment 13

[Myk Melez [:myk] [@mykmelez]]

Comment on attachment 130549 [details]
Bug List RSS template (update)

Sorry for the delay in reviewing.


><!DOCTYPE rss SYSTEM "http://my.netscape.com/publish/formats/rss-0.91.dtd">
><rss version="0.91">

Shouldn't we be generating an RSS 1.0-compliant feed?  It's backwards
compatible with 0.9x (and thus 2.0), but also compatible with 1.0, which is a
large and growing subset of RSS feeds and readers.


>    <link>[% Param('urlbase') %]buglist.cgi?[% urlquerypart.replace('&ctype=rss', '') FILTER url_quote %]</link>

You can't url_quote the urlquerypart here (and in the link tag below) because
that also quotes the equals and ampersands characters, which turns the
parameter list into one long search string.  Instead, use the "html" filter.

Also, the replacement won't catch the ctype parameter when it occurs at the
beginning of a query string (i.e. "?ctype=rss&...").  Changing the search
string to 'ctype=rss&?' should work, though.


>      <title>[% bug.short_short_desc %]</title>

Use short_desc to send the full summary rather than abbreviating it with
short_short_desc.  The abbreviated form was invented for the standard Bugzilla
HTML interface; third-party Bugzilla clients like RSS readers should get the
real data and take responsibility for massaging it into their UI.


>      <description>ID: [% bug.bug_id %] -  Assigned To: [% bug.assigned_to %] - Status: [% bug.bug_status %] - Priority: [% bug.priority %] - Severity: [% bug.bug_severity %] - Platform: [% bug.rep_platform %] - Resolution: [% bug.resolution %]</description>

Nit: I suggest semi-colons instead of dashes here.  Note only are they
narrower, they make the preceding space character unnecessary, so they reduce
the overall space required for this data.  Also, they can never be mistaken for
field/value separators, as dashes sometimes can.

Note that an entry needs to be added to the bottom of Bugzilla/Constants.pm for
the content type to associate with this format.  Assuming the name of this
template file will be list.rss.tmpl, that entry should look like this:

   "rss" => "text/xml" ,

Comment 14

[Myk Melez [:myk] [@mykmelez]]

Comment on attachment 130549 [details]
Bug List RSS template (update)

A few more notes:

>    <link>[% Param('urlbase') %]buglist.cgi?[% urlquerypart.replace('&ctype=rss', '') FILTER url_quote %]</link>

Long lines like this one should be wrapped at 80 characters where possible. 
Since whitespace before directives is automatically removed and whitespace
within directives is ignored, this could be the start of any directive or the
whitespace within it, f.e.:

    <link>[% Param('urlbase') %]buglist.cgi?
	  [% urlquerypart.replace('&ctype=rss', '') FILTER url_quote %]</link>

>      <url>[%Param('urlbase')%]ant.jpg</url>

Nit: spaces around directive contents.

>      <title>[% bug.short_short_desc %]</title>

This needs HTML filtering.

Comment 15

[Myk Melez [:myk] [@mykmelez]]

One more thing, ./runtests.sh has this to say:

not ok 85 - (en/default) template/en/default/list/list.rss.tmpl has unfiltered
directives:
#   38: template_version
#   43:numString
#   55: bug.short_short_desc
#   56: bug.bug_id
#   57: bug.bug_id
#   57: bug.assigned_to
#   57: bug.bug_status
#   57: bug.priority
#   57: bug.bug_severity
#   57: bug.rep_platform
#   57: bug.resolution
# --ERROR
#     Failed test (t/008filter.t at line 117)

Except for short_short_desc, these should all be OK unfiltered, but you need to
add the appropriate lines to template/en/default/filterexceptions.pl to get the
tests to ignore them.

Gerv, Bradley: can you confirm that these are ok unfiltered?

Comment 16

[Dave Miller [:justdave]]

I think bug_id is the only thing there that can stay unfiltered.  The rest are
all strings (not integers) and while they're hard-coded, there's no guarantee a
site won't customize them to something that needs to be quoted.

Comment 17

[Henri Sivonen (:hsivonen)]

> Shouldn't we be generating an RSS 1.0-compliant feed?

If only title-link pairs are needed, why go beyond RSS 0.9?

>   "rss" => "text/xml" , 

Using text/* types for XML is a can of worms in terms of the character encoding
rules. application/xml is a lot clearer, because there are no strange MIME
defaults and only the XML spec applies. 

Which brings up another point: How does this patch handle the character
encoding? To me, it looks like it doesn't address the issue. Isn't Bugzilla
still full of arbitrary encodings with no labeling? That makes the data unsuited
for export as XML. Given Bugzilla content with unknown encoding, the only safe
way to get well-formed XML is to drop all bytes whose value is > 127 decimal.

(Of course, the better way to address this is to fix Bugzilla so that all the
content is UTF-8-encoded. There's another bug for that, but I don't think it is
fixed in b.m.o, yet, due to legacy data.)

Comment 18

[Myk Melez [:myk] [@mykmelez]]

>If only title-link pairs are needed, why go beyond RSS 0.9?

So that clients which only support RSS 1.0 can also use the feed.

>Using text/* types for XML is a can of worms in terms of the character encoding
>rules. application/xml is a lot clearer, because there are no strange MIME
>defaults and only the XML spec applies. 

application/xml is fine with me.  Our existing RDF format uses it, actually,
although the existing XML format uses text/xml.

>Which brings up another point: How does this patch handle the character
>encoding? To me, it looks like it doesn't address the issue. Isn't Bugzilla
>still full of arbitrary encodings with no labeling?

No, although some Bugzilla installations may be.  b.m.o is fairly clear of them,
with a few exceptions.  This issue exists all over the Bugzilla codebase and is
well-defined by other bug reports; it doesn't need to be addressed by this one.

Comment 19

[Mark Nottingham]

Many consumers of RSS identify it with application/rss+xml, although that isn't registered with 
IANA.

Comment 20

[Gervase Markham [:gerv]]

/me agrees belatedly with Dave's assessment re: filtering.

Gerv

Comment 21

[Henri Sivonen (:hsivonen)]

Although the encoding issue exists elsewhere in the codebase, it is no reason
why the issue could or should be dodged here. The current patch doesn't declare
any character encoding in the XML declaration. If the content is delivered as
text/xml, the defaulting rules say it should be processed as US-ASCII. If it is
delivered as application/xml, the default is UTF-8. b.m.o content (including
titles) may contain byte sequences that are neither valid UTF-8 byte sequences
nor valid US-ASCII byte sequences. 

The XML spec (2nd ed.) says:
"It is a fatal error if an XML entity is determined (via default, encoding
declaration, or higher-level protocol) to be in a certain encoding but contains
octet sequences that are not legal in that encoding. It is also a fatal error if
an XML entity contains no encoding declaration and its content is not legal
UTF-8 or UTF-16."

Hence, if this issue is not addressed, the resulting XML document could be
ill-formed quite easily. Most b.m.o content could safely be treated as
windows-1252, but labeling an XML file to be windows-1252-encoded is not a good
idea, because XML processors are not required to support windows-1252 and the
XML spec says:

"It is a fatal error when an XML processor encounters an entity with an encoding
that it is unable to process."

In my opinion, dropping non-ASCII (pending the fixes for the root cause design
bug) is a better solution that letting the result turn out to be ill-formed once
in a while. If the result turns out to be ill-formed, you lose everything--not
just the non-ASCII characters. (In a conforming XML processor, that is. Mozilla
is not conforming is this respect, but there's another bug about that.)

Comment 22

[Myk Melez [:myk] [@mykmelez]]

Interestingly, Mozilla Firebird treats the output of xml.cgi as UTF-8 even
though its content type is text/xml and the output itself doesn't specify an
encoding.

I understand that not specifying an encoding (or specifying an incorrect one)
can cause XML parsers to fail to parse a document, and this should be fixed, but
since our existing XML output doesn't specify an encoding (and works fine most
of the time anyway), I'm not going to require this implementation to fix that
problem independently of the general Bugzilla encoding issues (f.e. bug 126266,
bug 105960).  If you want the encoding issues resolved, please contribute to
those bugs or file a new one if none of those address your concerns.

Comment 23

[Jouni Heikniemi]

I've been toying with this a bit. I need some ideas on the following stuff:

1) Ability to construct a reasonable RSS feed requires that certain fields are
selected. This may not be the default, so list.rss.tmpl doesn't end up with bug
objects that contain enough information. The column list can of course be
specified through an URI parameter, but that's not really good (for example, to
get new fields added to your feeds would require changing your RSS feed bookmark).

Essentially, the easiest way would be to make the columnset for the RSS feed
fixed. Again, this easily results in buglist.cgi being fairly tightly coupled
with the template.

2) For the RSS to be really useful, we should make the items contain <pubDate>s
or <dc:date>s with the content of delta_ts, so you could essentially monitor
changes occurring in the query. However, for that we need special date
formatting. Doing that in buglist.cgi (like we do for current changeddate) is
fishy, because we then end up binding one part of the RSS implementation into
buglist.cgi anyway. 

I think the best approach would be to just pass delta_ts into the template and
then make the date formatting occur there. This would also make localizations
easier. However, I'm not familiar with TT's date formatting. Ideas on this one?


Gerv? Myk?

Comment 24

[Myk Melez [:myk] [@mykmelez]]

>1) Ability to construct a reasonable RSS feed requires that certain fields
>are selected. This may not be the default, so list.rss.tmpl doesn't end up
>with bug objects that contain enough information.

I don't understand, why not just use the default?


>Essentially, the easiest way would be to make the columnset for the RSS 
>feed fixed. Again, this easily results in buglist.cgi being fairly tightly
>coupled with the template.

If you can't use the regular default, substitute an RSS-specific default, but
let the user override it via the columnlist parameter.  A couple lines like the
following in buglist.cgi should solve this problem:

if (content type is RSS && no columnlist specified) {
  set columnlist to default columnlist for RSS;
}


>2) For the RSS to be really useful, we should make the items contain 
><pubDate>s or <dc:date>s with the content of delta_ts, so you could 
>essentially monitor changes occurring in the query.
...
>I think the best approach would be to just pass delta_ts into the template 
>and then make the date formatting occur there.

I agree.


>However, I'm not familiar with TT's date formatting. Ideas on this one?

Use TT's Date plugin, for which more info is available here:

http://www.template-toolkit.org/docs/green/Manual/Plugins.html#Date

Note that RSS dates should be in ISO 8601 format, a simplified subset of which
is described here:

http://www.w3.org/TR/NOTE-datetime

Comment 25

[John Belmonte]

Attachment: experimental RSS 1.0 with column control

This template generates RSS 1.0.  I let the query determine what bug attributes
are displayed in the item description.	For example, an RSS feed of new bugs
from the last 10 days, with product and reporter listed in the description:

buglist.cgi?columnlist=short_short_desc+product+reporter&chfieldfrom=10d&chfieldto=Now&chfield=%5BBug%20creation%5D&ctype=rss


Note that short_short_desc must always be included in the columnlist, as it is
used in the item title.

ISSUES:
  * need a way for buglist.cgi to list items in descending order by ID (I think
this is an existing bug)
  * need a way for buglist.cgi to limit the number of bugs returned (to me this
is generally useful and should be filed as a bug)

Anyway, I think this template approach is wrong.  There should only be code to
generate XML, and all other representations should be produced with an XSLT
transformation.

Comment 26

[John Belmonte]

I found the way to sort by descending bug ID, so I withdraw that issue.  Here is
the updated example query:

buglist.cgi?columnlist=short_short_desc+product+reporter&chfieldfrom=10d&chfieldto=Now&chfield=%5BBug%20creation%5D&order=bugs.bug_id+desc&ctype=rss

I forgot to mention that the link in the RSS to the HTML version of the bug list
will be broken if ctype=rss is the first query parameter (because the script
searches for "&ctype=rss".  The previous template (for RSS 0.91) has the same issue.

Comment 27

[John Belmonte]

Attachment: experimental RSS 1.0 with column control

This version improves the description formatting, adds an item limit variable,
and includes some documentation.

Comment 28

[slyi]

(In reply to comment #27)
> Created an attachment (id=141968) [edit]
> experimental RSS 1.0 with column control
> This version improves the description formatting, adds an item limit 
variable,
> and includes some documentation.

Heres a basic version that does it by parsing the csv file in php
http://www.php.net/manual/en/function.fgetcsv.php (see user comments)

Comment 29

[Jason Remillard]

Attachment: New RSS 1.0 Patch

This is a  patch for the existing files in bugzilla against current 2.19
release. There is also a new template rss file that will be attatched next. It
mostly deals with the mime type, and the date formatting.

Comment 30

[Jason Remillard]

Attachment: New list.rss.tmpl file

This goes with the patch that I just put in. It is the list.rss.tmpl file.

Comment 31

[Jason Remillard]

I just put in patch for RSS support (2005-02-19). It is a cleanup of the
existing patch to deal with the issues that were not resolved from the first review.

1. I think everything is escaped correctly in the template file now.
2. It will not break if the ctype is the first parameter in the url.
3. The mime type was changed to application/rss+xml. 
4. I added a RSS link next to the ical link.
5. I added support for the live bookmarks ala firefox.
6. It does the date formatting correctly.
7. buglist.cgi know what params the rss feed needs, and will insure they are
generated regardless of what is on the url.
8. It passes the runtests.pl script.
9. The ICS specific date formatting has been removed from buglist.cgi, and
replaced with template toolkit date filter.

The unicode issue is not fixed. I don't want to wait for bug 126266.

The patch is against the 2.19 tip. I did the patch so that engineers can use RSS
to get a quick todo view from bugzilla. ICS is not available in the calander
application that we use.

Comment 32

[Myk Melez [:myk] [@mykmelez]]

Comment on attachment 174825 [details] [diff] [review]
New RSS 1.0 Patch 

>Index: buglist.cgi

>< sub iCalendarDateTime {

Yum, what a great fix reducing our code complexity by offloading date
processing to existing modules specialized for the task.


>> if ($format->{'extension'} eq 'rss') {
>>     my @required_rss_columns = 
>>        (
>>        'short_desc',
>>        'opendate',
>>        'reporter_realname',
>>        'changeddate',
>>        'opendate',
>>        'priority',
>>        'bug_severity',
>>        'assigned_to_realname',
>>        'bug_status'
>>        );

opendate is in the list twice, and changeddate isn't in it at all, although
later code seems to require it.  Also, per Bugzilla formatting convention, do:

my @required_rss_columns = (
  'short_desc',
  'opendate',
  'reporter_realname',
  'changeddate',
  'opendate',
  'priority',
  'bug_severity',
  'assigned_to_realname',
  'bug_status'
);


>>     $bug->{'changedate_time'} = str2time($bug->{'changedate'});
>>     $bug->{'opendate_time'} = str2time($bug->{'opendate'});

changedate -> changeddate

We should be consistent with existing names, i.e. "changed" and "open" rather
than "change" and "open" (despite the existing inconsistency).	Also, given the
current naming convention for columns, we probably shouldn't use underscores in
their name, and given the meaning of "datetime" in MySQL and "time" in Perl,
these would probably be better named "changedtime" and "opentime",
respectively.


>Index: template/en/default/list/list.ics.tmpl

>> [%+ date.format(bug.changeddate_time,"%Y%m%dT%H%M%SZ") FILTER ics('LAST-MODIFIED') +%]

changeddate_time -> changedate_time
(but see previous comment about variable naming)


>73c73
><   [% currenttime FILTER ics('DTSTAMP') %]
>---
>>   [% date.format(currenttime,"%Y%m%dT%H%M%SZ") FILTER ics('DTSTAMP') %]

You've removed currenttime from buglist.cgi.  I think you want date.now here
instead.

Comment 33

[Jason Remillard]

Attachment: New RSS 1.0 Patch v2

Fixes from Myk Melez review, see comment #32.

Comment 34

[Jason Remillard]

Attachment: New list.rss.tmpl file v2

Updated list.rss.tmpl from Myk Melez review, see comment #32.

Comment 35

[Myk Melez [:myk] [@mykmelez]]

Comment on attachment 175506 [details] [diff] [review]
New RSS 1.0 Patch v2

>Index: buglist.cgi

>+        # Put in the change date as a time, so that the template date plugin
>+        # can format the date in any way needed by the template. ICS and RSS
>+        # have specific, and different, date and time formatting.
>+        $bug->{'changedtime'} = str2time($bug->{'changedate'});

changedate -> changeddate


>Index: template/en/default/global/header.html.tmpl

>+       <link rel="alternate" 
>+        type="application/rss+xml" title="RSS 1.0" 
>+    href="[% rsslink FILTER uri %]" />

Nit: per convention:

       <link rel="alternate" 
	     type="application/rss+xml" title="RSS 1.0" 
	     href="[% rsslink FILTER uri %]" />

All, rsslink gets constructed from urlquerypart, and urlquerypart appears to be
URI escaped already.  It does not appear to be HTML escaped, however.  So this
needs to be HTML escaped rather than URI escaped, i.e.:

	     href="[% rsslink FILTER html %]" />


>Index: template/en/default/list/list.html.tmpl

>+  rsslink = "buglist.cgi?$urlquerypart&amp;ctype=rss" 

If we're going to HTML escape this in header.html.tmpl, its characters
shouldn't be HTML escaped already, so:

&amp; -> &

>       <td valign="middle">
>         <a href="buglist.cgi?
>         [% urlquerypart FILTER html %]&amp;ctype=csv">CSV</a> |
>+    <a href="buglist.cgi?
>+    [% urlquerypart FILTER html %]&amp;ctype=rss">RSS</a> |

Nit: indent eight spaces as with CSV and iCalendar links.

Comment 36

[Myk Melez [:myk] [@mykmelez]]

Comment on attachment 175507 [details]
New list.rss.tmpl file v2

>[%# [e-mail] %/

/ -> ]


>  # As buglist queries do not let you specify the maximum items to return,
>  # you may enforce a limit by setting the max_items variable below to
>  # a non-zero value.

Actually you can set the "limit" URL parameter to the maximum number of results
to return, i.e.:

buglist.cgi?limit=10


><?xml version="1.0"?>
><rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" 
>         xmlns:sy="http://pur1.org/rss/1.0/modules/syndication/"
>     xmlns:dc="http://pur1.org/rss/dc/elements/1.1/"

Nit: eight spaces of indentation, as with the other namespaces.


>         xmlns="http://purl.org/rss/1.0/">
>  <channel rdf:about="[% Param('urlbase') %]buglist.cgi?[% 
>       urlquerypart.replace('ctype=rss[&]?','') FILTER xml %]" >

Nit: use chomping rather than multi-line directives to remove whitespace here
and elsewhere, i.e.:

  <channel rdf:about="[% Param('urlbase') %]buglist.cgi?
		      [%- urlquerypart.replace('ctype=rss[&]?','') FILTER xml
%]">

(It makes the code a lot more readable.)


>    <dc:creater>[% bug.reporter_realname FILTER xml %]</dc:creater>

creater -> creator


>    <description>
>      [% bug.short_desc FILTER xml %] &lt;p>
>      [% columns.opendate.title FILTER xml %] - [% bug.opendate FILTER xml %] 
>      [% columns.priority.title FILTER xml %] - [% bug.priority FILTER xml %] 
>      [% columns.bug_severity.title FILTER xml %] - [% bug.bug_severity FILTER xml %] 
>      [% columns.assigned_to_realname.title FILTER xml %] - [% bug.assigned_to_realname FILTER xml %] 
>      [% columns.bug_status.title FILTER xml %] - [% bug.bug_status FILTER xml %] 
>      [% columns.changeddate.title FILTER xml %] - [% bug.changeddate FILTER xml %]
>    </description>

Is there a better way to format this, f.e. an HTML table, since one can embed
HTML in an RSS item description?

Comment 37

[Jason Remillard]

Attachment: RSS 1.0 patch v3

Fixes all of the issues in comment 35.

Comment 38

[Jason Remillard]

Attachment: new list.rss.tmpl file v3

Fixes all of the issues in comment 36.

Comment 39

[Myk Melez [:myk] [@mykmelez]]

Comment on attachment 175782 [details] [diff] [review]
RSS 1.0 patch v3

>Index: template/en/default/list/list.html.tmpl

>+  rsslink = "buglist.cgi?$urlquerypart;ctype=rss" 

; -> &

Otherwise this is good.

Comment 40

[Myk Melez [:myk] [@mykmelez]]

Comment on attachment 175783 [details]
new list.rss.tmpl file v3

>[%# [e-mail] %]
>[%# The contents of this file are subject to the Mozilla Public
>  # License Version 1.1 (the "License"); you may not use this file
>  # except in compliance with the License. You may obtain a copy of
>  # the License at http://www.mozilla.org/MPL/
>  #
>  # Software distributed under the License is distributed on an "AS
>  # IS" basis, WITHOUT WARRANTY OF ANY KIND, either express or
>  # implied. See the License for the specific language governing
>  # rights and limitations under the License.
>  #
>  # The Original Code is the Bugzilla Bug Tracking System.
>  #
>  # The Initial Developer of the Original Code is Netscape Communications
>  # Corporation. Portions created by Netscape are
>  # Copyright (C) 1998 Netscape Communications Corporation. All
>  # Rights Reserved.
>  #
>  # Contributor(s): Walter Hoehn <[e-mail]>
>  #                 John Belmonte <[e-mail]>
>  #                 Jason Remillard <[e-mail]>
>  #
>  # This is a template for generating an RSS 1.0 representation of a buglist. 
>  # It is used by setting up your query in the advanced search page and
>  # then copying the url in the RSS link into your RSS reader. If you would
>  # like to limit the number of RSS items, use the limit=n CGI parameter on
>  # buglist.cgi.

Nit: usage info would be better put into the Bugzilla Guide.


>      &lt;table>
>      &lt;tr>
    ...

Nit: for consistency, replace greater than signs with their encoding, too.


>      &lt;td>[% columns.opendate.title FILTER xml %] &lt;/td>&lt;td>- [% bug.opendate FILTER xml %]

There's no need to separate column titles from their values with "-" anymore,
since you're segregating them into different columns.  Also, use <th> for table
cells containing column titles, and close all table cells.

Comment 41

[Myk Melez [:myk] [@mykmelez]]

Comment on attachment 175783 [details]
new list.rss.tmpl file v3

>    <description>
>      &lt;table>
>      &lt;tr>
       ....
>      &lt;/tr>
>      &lt;/table>
>    </description>

Or use a CDATA section to make the source more readable, since you don't have
to escape special characters within it, i.e.:

<description><![CDATA[
      <table>
      <tr>
      ....
      </tr>
      </table>
]]></description>

Comment 42

[Jason Remillard]

Attachment: RSS 1.0 patch v4

Fixed problems in comment 39 and 40, and added section in the manual for RSS,
iCal, and ctype.

Comment 43

[Jason Remillard]

Attachment: new list.rss.tmpl file v4

Used template toolkit to escape out html comment block. I left in the -,
because it was harder to read without it. Address comment 40 and 41.

Comment 44

[Myk Melez [:myk] [@mykmelez]]

Comment on attachment 177337 [details] [diff] [review]
RSS 1.0 patch v4

>+    <para>
>+      If you would like to access the bug list from another program 
>+      it is often useful to have the list returned in 
>+      something other than html. By adding the ctype=type parameter 
>+      into the buglist url you can specify several alternate 
>+      formats. The supported formats are: Comma Seperated Text 
>+      file (ctype=cvs), iCalendar (ctype=ics), RDF Site Summary (RSS) 
>+      2.0 (ctype=rss), ECMAScript also known as javascript (ctype=js),
>+      and finally in Resource Description Framework RDF/XML (ctype=rdf).
>+    </para>

A few nits:

html -> HTML
Seperated -> Separated
2.0 -> 1.0
javascript -> JavaScript

Comment 45

[Myk Melez [:myk] [@mykmelez]]

Comment on attachment 177338 [details]
new list.rss.tmpl file v4

>        <td id="open">[% columns.opendate.title FILTER none %]</td>
>        <td headers="open">- [% bug.opendate FILTER none %]</td>

Nit: the first td should be a th here and elsewhere.

Comment 46

[Jason Remillard]

(In reply to comment #44)
> (From update of attachment 177337 [details] [diff] [review] [edit])
> 
> A few nits:
> 
> html -> HTML
> Seperated -> Separated
> 2.0 -> 1.0
> javascript -> JavaScript
> 

Should I do another patch with these changes? 

(In reply to comment #45)
> (From update of attachment 177338 [details] [edit])
> >        <td id="open">[% columns.opendate.title FILTER none %]</td>
> >        <td headers="open">- [% bug.opendate FILTER none %]</td>
> 
> Nit: the first td should be a th here and elsewhere.
> 

I can't use th because of how the data is formatted. Each row has two headers
and two data cells.

header, data, header, data.

My reading of the w3c <th> specification says that it is used when the first row
or column is the header, and the rest are data. This is not how this table is
setup. The headers attribute is a replacement which will serve the same function
as the th.

I am not really a hard core html guy, so I would not be offended if one of the
people working on bugzillas html/style sheets takes a look at this.

Comment 47

[Myk Melez [:myk] [@mykmelez]]

> Should I do another patch with these changes?

No, I can fix these before checking in the patch.
 

> I am not really a hard core html guy, so I would not be offended if one of the
> people working on bugzillas html/style sheets takes a look at this.

I suggest a layout like the following:

+--------+------------------------+
| header | data                   |
+--------+------------------------+
| header | data                   |
+--------+------------------------+
| header | data                   |
+--------+------------------------+
| header | data                   |
+--------+------------------------+

It works well for simple presentation of a small list of fields like in this
case.  See the mozilla.org module owners list for an example:

http://www.mozilla.org/owners.html

Ultimately we probably want to put a more complete Bugzilla description into
this field, which will necessitate UI changes, but a simple table works fine for
now.  The version above also makes it possible to use th tags for the header
cells.  If that version sounds good to you, spin me up another patch and I'll
review, approve, and check it in!  Otherwise, I'll check in the current version,
which works well enough and implements the feature this report is requesting.

Comment 48

[Jason Remillard]

Attachment: new list.rss.tmpl file v5 - 2 col table with th

Changes format of the description to have a two column table with proper <th>
labels. This should do it.

Comment 49

[Myk Melez [:myk] [@mykmelez]]

Thanks for the fix Jason!  I've checked it in.

Checking in Bugzilla/Constants.pm;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/Constants.pm,v  <--  Constants.pm
new revision: 1.21; previous revision: 1.20
done
Checking in docs/xml/using.xml;
/cvsroot/mozilla/webtools/bugzilla/docs/xml/using.xml,v  <--  using.xml
new revision: 1.27; previous revision: 1.26
done
Checking in template/en/default/global/header.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/global/header.html.tmpl,v
 <--  header.html.tmpl
new revision: 1.39; previous revision: 1.38
done
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.34; previous revision: 1.33
done
Checking in template/en/default/list/list.ics.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/list/list.ics.tmpl,v  <--
 list.ics.tmpl
new revision: 1.4; previous revision: 1.3
done
RCS file:
/cvsroot/mozilla/webtools/bugzilla/template/en/default/list/list.rss.tmpl,v
done
Checking in template/en/default/list/list.rss.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/list/list.rss.tmpl,v  <--
 list.rss.tmpl
initial revision: 1.1
done

Comment 50

[Myk Melez [:myk] [@mykmelez]]

Missed a file:

Checking in buglist.cgi;
/cvsroot/mozilla/webtools/bugzilla/buglist.cgi,v  <--  buglist.cgi
new revision: 1.286; previous revision: 1.285
done

Comment 51

[Frédéric Buclin]

For the record, this feature has been implemented in 2.19.3.

Comment 52

[Frédéric Buclin]

reassigning to patch author

Comment 53

[Max Kanat-Alexander]

Added to the release notes in bug 286274.