235459 - add icalendar todo output format for buglist

Status: RESOLVED FIXED

(Bugzilla :: Query/Bug List, enhancement)

Description

[William Jon McCann]

User-Agent:       
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040207 Firefox/0.8

I have a patch that adds iCal output to the buglist.  This is very useful for
integrating bugzilla with calendars and PIMs.

It is implemented as a list template for the ics ctype.

Reproducible: Always
Steps to Reproduce:
1.
2.
3.

Comment 1

[William Jon McCann]

Attachment: new file for template/en/default/list

Comment 2

[William Jon McCann]

Attachment: patch to add mime type and add origdate to selected fields

Comment 3

[William Jon McCann]

Attachment: patch to add download option to default bug list template

Comment 4

[Dave Miller [:justdave]]

Attachment: Combined patch

Ooooh!	::justdave drools::

This is William's original patch, unmodified, but combined into a single patch
file for ease of use.

I have it installed at http://landfill.bugzilla.org/bzdave/ if anyone wants to
play.

I already tested it and it works great on my copy of iCal. :)

My only comment...  iCal uses an industry standard file format for that... Do
we want to label the button "iCal" or should we make it more generic?  This
stuff works with more than just iCal...

Comment 5

[Dave Miller [:justdave]]

The attached URL is the RFC specifying this file format.

Comment 6

[William Jon McCann]

Right, I used iCal since it is immediately recognizable and short for iCalendar
<http://www.faqs.org/rfcs/rfc2445.html>.  Perhaps iCalendar is better though.

Two comments about my patch:

- might be nice to get a DESCRIPTION in there but that probably means selecting
longdescs and might be expensive

- might be better not to hard code status names like RESOLVED, CLOSED, ASSIGNED
but I couldn't figure out how

Comment 7

[Gervase Markham [:gerv]]

This patch has a few too many format-specific hacks for my liking. 

I have some comments and zero time - I need to come back to this - but here is
one - who's to say that the priorities are given in the array in decreasing
order? I can't see a simple solution to that one.

Gerv

Comment 8

[William Jon McCann]

Attachment: updated list.ics.tmpl

Here is an updated template that:
- doesn't use priority because there is no way to properly order priority
labels
- uses a more conventional UID style
- doesn't html filter everything
- doesn't hard-code closed states
- doesn't use DTSTART because origdate is not always returned as a date
- does uri filtering on the URL field
- adds a few useful non-standard properties

Sorry I couldn't produce a single patch.  I think cvs add permission is needed
to do a cvs diff -N.

Comment 9

[Vlad Dascalu]

> Sorry I couldn't produce a single patch.  I think cvs add permission is needed
> to do a cvs diff -N.

You can diff againest /dev/null if it exists on your platform/OS. The resulting 
diff can then be appended at the bottom of the "normal" diff.

Comment 10

[William Jon McCann]

Attachment: combined patch

vlad: Thanks for the help.

Comment 11

[Gervase Markham [:gerv]]

Comment on attachment 142346 [details] [diff] [review]
combined patch

>Index: buglist.cgi
>===================================================================
>+if ($format->{'ctype'} == 'ics') {
>+    $vars->{'priorities'} = \@::legal_priority;
>+}
>+

You don't need this any more.

>+SUMMARY:[% bug.short_short_desc FILTER remove('\n') FILTER truncate(255) %]

If you are truncating, I think you want short_desc rather than
short_short_desc. But I could be wrong.

Gerv

Comment 12

[William Jon McCann]

Attachment: updated patch

+ Removed changes to buglist.cgi.
+ Use BLOCKs in template to improve readability.
+ Try to construct a SUMMARY from: short_desc, short_short_desc, "$terms.Bug
$bug.bug_id" in that order.

Gerv: the truncation is just there to satisfy Recommended Practice (Sec. 6)
item 6 in the RFC.  Any summary longer than that is probably bogus anyway.

Comment 13

[Dave Miller [:justdave]]

Comment on attachment 142379 [details] [diff] [review]
updated patch

r= justdave

Comment 14

[Dave Miller [:justdave]]

The most-recent patch is live on http://landfill.bugzilla.org/bzdave/ again. 
(Dunno how long it'll stay there ;)

Comment 15

[Vlad Dascalu]

Checking in Bugzilla/Constants.pm;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/Constants.pm,v  <--  Constants.pm
new revision: 1.6; previous revision: 1.5
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.23; previous revision: 1.22
done
RCS file:
/cvsroot/mozilla/webtools/bugzilla/template/en/default/list/list.ics.tmpl,v
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
initial revision: 1.1
done

Comment 16

[Vlad Dascalu]

Tree's on fire due to the checkin.

Comment 17

[Vlad Dascalu]

runtests.sh --verbose reports:

not ok 97 - (en/default) template/en/default/list/list.ics.tmpl has unfiltered
directives:
   24: VERSION
   28: bug.bug_id
   29: bug.bug_id
   33: bug.product
   36: bug.component
   39: bug.version
   42: bug.keywords
   63: status
   74: summary FILTER remove('\n') FILTER truncate(255)
 --ERROR
     Failed test (t/008filter.t at line 117)

Comment 18

[Vlad Dascalu]

Attachment: Restoring tree to green patch

Comment 19

[Vlad Dascalu]

Not sure if HTML is the best choice.

http://www.ietf.org/rfc/rfc2445.txt

3.4 Encoding Considerations
    This MIME content type can contain 8bit characters, so the use of
    quoted-printable or BASE64 MIME content-transfer-encodings might be
    necessary when iCalendar objects are transferred across protocols
    restricted to the 7bit repertoire. Note that a text valued property
    in the content entity can also have content encoding of special
    characters using a BACKSLASH character (US-ASCII decimal 92)
    escapement technique. This means that content values can end up
    encoded twice.

    There is not a property parameter to declare the character set used
    in a property value. The default character set for an iCalendar
    object is UTF-8 as defined in [RFC 2279].

Thanks to kiko for the help.

Comment 20

[Christian Reis]

Section 4.7 in the RFC describes each fieldtype, checking to see what's appropriate.

Comment 21

[Vlad Dascalu]

<kiko> vladd: status can be filter none
<kiko> version can be filter none

We're left with summary, product, component, version and keywords.

Comment 22

[Vlad Dascalu]

<kiko> vladd: I'd suggest backing out the patch and waiting to see what dave thinks.

Yeah, the hour is up anyway.

Kiko suggests to look into UTF-8 conversions issues as well. Maybe we need an
ICS filter?

Sections from the documentation that got explored: (
http://www.ietf.org/rfc/rfc2445.txt )

3.4
4.7
4.8.8.1

Backing out checkin.

Checking in Bugzilla/Constants.pm;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/Constants.pm,v  <--  Constants.pm
new revision: 1.7; previous revision: 1.6
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.24; previous revision: 1.23
done
Removing template/en/default/list/list.ics.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/list/list.ics.tmpl,v  <--
 list.ics.tmpl
new revision: delete; previous revision: 1.1
done

Comment 23

[Vlad Dascalu]

Comment on attachment 142594 [details] [diff] [review]
Restoring tree to green patch

This is not quite the right thing.

Comment 24

[Vlad Dascalu]

Clearing the a+ flag in order to get this off the radar regarding the "Ready to
checkin" query.

Comment 25

[Vlad Dascalu]

Comment on attachment 142158 [details] [diff] [review]
Combined patch

This is obsolete as well AFAIK.

Comment 26

[Gervase Markham [:gerv]]

<kiko> vladd: status can be filter none
<kiko> version can be filter none

Does the iCal standard really allow absolutely anything here?

Whatever filter we use needs to do folding before 75 octets (section 4.1).
We should probably quote every property parameter, so we don't need to search
for embedded commas, semicolons etc. (section 4.1.1).

<looks more> Wow, this standard sucks.

Gerv

Comment 27

[Vlad Dascalu]

>> Does the iCal standard really allow absolutely anything here?

Well we talked about this too:

<kiko> status is generated in the block, it's a hardcoded string
<kiko> version is only generated by bugzilla, and if the person puts bogus stuff
in their versions, then the whole of bugzilla will be a problem anyway

Comment 28

[Gervase Markham [:gerv]]

> <kiko> status is generated in the block, it's a hardcoded string

That's OK, then.

> <kiko> version is only generated by bugzilla, and if the person puts bogus stuff
> in their versions, then the whole of bugzilla will be a problem anyway

Not at all :-) We escape it properly everywhere else. 

Gerv

Comment 29

[Gervase Markham [:gerv]]

Oh, and don't use FILTER none - that's only supposed to be used in the error
templates, where we have a rule that _everything_ must be filtered - to make
people think very hard about what bogus data the error could print. 

The correct way to not filter a value is to add it to the exceptions list - then
the list is complete, and can be audited properly later.

Gerv

Comment 30

[Vlad Dascalu]

Justdave, were we are with this one? Can we forget about internationalization
support (UTF-8 --> UTF-16 conversion and the like)? We're not too good in this
field right now either.

Maybe check this in and exclude ics from the filter test just like txt is, like
you suggested, and open a new bug then to say that the current implementation of
ical is not perfect.

Comment 31

[William Jon McCann]

Is there anything I can do to help at this point?  Is this a policy matter?  I'm
just a little bit confused.

Comment 32

[Daniel Berlin]

Without dtstart, iCal can't read these.
Debug output from ical says:

2004-03-05 23:21:47.790 iCal[19537] ValidityFailure Todo must have dtstart property:<CFDictionary 
0x49d4f70 [0xa01900e0]>{type = mutable, count = 2, capacity = 4, pairs = (
        2 : <CFString 0xa483135c [0xa01900e0]>{contents = "Properties"} = <CFArray 0x49d4f60 
[0xa01900e0]>{type = immutable, count = 1, values = (
        0 : <CFString 0xa48309ac [0xa01900e0]>{contents = "DTSTART"}
)}
        3 : <CFString 0xa483134c [0xa01900e0]>{contents = "Reason"} = <CFString 0xa483133c 
[0xa01900e0]>{contents = "Todo must have dtstart property"}
)} for ...

Comment 33

[Dave Miller [:justdave]]

Comment on attachment 142379 [details] [diff] [review]
updated patch

r- based on comment 32...

Comment 34

[Dave Miller [:justdave]]

ok....  brainstorming time...

I believe when you create user-defined filters for Template Toolkit that you can
pass additional parameters to the filter...  the sub that gets called for the
filter has the data to be filtered as the first argument and any params you
passed following that.

So we could do something like this:

[% bug.product FILTER ics('X-BUGZILLA-PRODUCT') %]

And have the ics filter take care of doing the folding at 75 columns (which is
why we pass the field name, since that counts towards the line length.  The
filter could also take care of any needed encoding within fields if they need
it, but since it looks like the format is 8-bit clean, we probably don't need it
for anything we'd do (this would mainly affect binary data, and we don't have any)

Comment 35

[Christian Reis]

(In reply to comment #31)
> Is there anything I can do to help at this point?  Is this a policy matter?  
> I'm just a little bit confused.

It's not really a policy matter: the problem is that the values we are
outputting in the ICS file need to be properly filtered according to the
standard (or else we will generate broken ICS). The filtering rules aren't too
clear to me, but I think a good read of the spec would be sufficient to write a
simple ICS filter as Gerv and Dave are proposing. You *can* help by implementing
that filter (look at Bugzilla/Template.pm:create() for a look at other filters),
or by parsing the spec and telling us what the filter would need to do (starting
with Gerv's observations at comment 26).

Comment 36

[Christian Reis]

(In reply to Gervase Markham in comment #28)
>> <kiko> version is only generated by bugzilla, and if the person puts bogus 
>> stuff in their versions, then the whole of bugzilla will be a problem anyway
> Not at all :-) We escape it properly everywhere else. 

./bug/show.xml.tmpl:
    <bugzilla version="[% VERSION %]"

./global/banner.html.tmpl:      
    <a href="http://www.bugzilla.org/">Bugzilla</a> Version [% VERSION %]

Should I file bugs?

Comment 37

[William Jon McCann]

(In reply to comment #32)
> Without dtstart, iCal can't read these.

Works fine for me with iCal 1.5.2 (v637) on OS X 10.3.  Furthermore, the spec 
says that DTSTART is optional for VTODO components.

Comment 38

[William Jon McCann]

Attachment: updated patch with an ics filter

Comment 39

[Christian Reis]

Caught Gerv on IRC and clarified this point:

(In reply to comment #28)
> > <kiko> version is only generated by bugzilla, and if the person puts bogus 
> > stuffin their versions, then the whole of bugzilla will be a problem anyway
> 
> Not at all :-) We escape it properly everywhere else. 

<Gerv> Ah, I got confused.
<Gerv> I thought you meant the version field.
<Gerv> You actually meant the Bugzilla version.
<Gerv> No, that doesn't need escaping - you are right.

Comment 40

[Vlad Dascalu]

Comment on attachment 143339 [details] [diff] [review]
updated patch with an ics filter

Nice work.

We still need UTF-8 --> UTF-16 conversion and stuff like that but we're far
from getting there, and this has a pretty stable support that worths checking
in now.

You should run ./runtests.pl to test your diff. In this case, test number 8
(the filtering test) whines about unescaped directives, because you haven't
added "ics" as a filter in the file t/008filter.t (at the bottom).

However, that's a trivial change, it can be added upon cvs commit.

Comment 41

[Daniel Berlin]

(In reply to comment #37)
> (In reply to comment #32)
> > Without dtstart, iCal can't read these.
> 
> Works fine for me with iCal 1.5.2 (v637) on OS X 10.3.  Furthermore, the spec 
> says that DTSTART is optional for VTODO components.
> 

Which version of the patch did you use.
I've tried multiple times with the version that does not include DTSTART, and iCal refuses to import 
them.
Same iCal version as you, on OS X 10.3.

Comment 42

[Christian Reis]

Comment on attachment 143339 [details] [diff] [review]
updated patch with an ics filter

>Index: Bugzilla/Template.pm
>+            # iCalendar contentline filter
>+            ics => [ sub {
>+                         my ($context, @args) = @_;
>+                         return sub {
>+                             my ($var) = shift;
>+                             my ($par) = shift @args;
>+                             my ($output) = "";

Would it be possible to unpack using:

  my (($var), ($par)) = @args; 

here and avoid the shifts?

>+
>+                             $var =~ s/[\r\n]/ /g;
>+                             $var =~ s/([;\\\"])/\\$1/g;
>+
>+                             if ($par) {
>+                                 $output = sprintf("%s:%s", $par, $var);
>+                             } else {
>+                                 $output = $var;
>+                             }
>+                             
>+                             $output =~ s/(.{75,75})/$1\n /g;
>+
>+                             return $output;
>+                         };
>+                     },
>+                     1
>+                     ],

Hmm. Would it be too much to ask to follow the indentation in that file, which
would have something like:

  ics => sub
  {
      my foo;
      ...
  }

Would it be possible to avoid having the filter return a sub and process the
argument directly in the filter sub? I get a feeling you've done that for a
reason, but it's not clear to me why -- perhaps add a comment?

I also don't know what the brackets and 1; get us, but maybe it's there for a
good reason.

I've skimmed over the rest and it looks okay, but I might like to take a second
look.

Comment 43

[William Jon McCann]

(In reply to comment #42)
> (From update of attachment 143339 [details] [diff] [review]) 
> Would it be possible to unpack using:
> 
>   my (($var), ($par)) = @args; 
> 
> here and avoid the shifts?

I suppose.  I'm not sure which is better.  I used shift since I don't know how
the above will handle an args array of length 3.  I used shift so it would
silently ignore the rest of the @args.  Your suggestion looks cleaner though.

> Hmm. Would it be too much to ask to follow the indentation in that file, which
> would have something like:
> 
>   ics => sub
>   {
>       my foo;
>       ...
>   }

I was following the indentation style used for the other dynamic filter,
bug_link.  I could change it but I was trying to use the existing style :)

> Would it be possible to avoid having the filter return a sub and process the
> argument directly in the filter sub? I get a feeling you've done that for a
> reason, but it's not clear to me why -- perhaps add a comment?
> 
> I also don't know what the brackets and 1; get us, but maybe it's there for a
> good reason.

Both of these are because it seems that a dynamic filter is required when
passing arguments to the filter.  See
http://template-toolkit.org/docs/plain/Modules/Template/Filters.html#CONFIGURATION_OPTIONS

Comment 44

[Christian Reis]

(In reply to comment #43, regarding indentation and the inline function)
> Both of these are because it seems that a dynamic filter is required when
> passing arguments to the filter.

You're right. Ignore those parts of my comment.

Comment 45

[Daniel Berlin]

Attachment: bugs.ics

This was produced from the landfill installation with the latest patch
attached.
It has no DTSTART entries (as allowed by the spec).
Please try it with ical, and you will note not a single entry will be imported
properly.

Comment 46

[Dave Miller [:justdave]]

Comment on attachment 143339 [details] [diff] [review]
updated patch with an ics filter

OK, played around with this...	probably better than half of the people who
would actually use this feature will be using Apple's iCal, and it is indeed
choking on the output of the current patch (I tried it myself).  Regardless of
this actually being a bug in iCal if we follow the RFC, it's a popular enough
app that there's no reason we shouldn't work around it.  Especially since the
workaround itself won't violate the RFC either.

Comment 47

[Christian Reis]

As a hint, what we need to do (to include DTSTART in all bugs output in ICS
format) is ensure bug.opendate will be available to the template; this involves
changing buglist.cgi to enforce "opendate" to be present in @selectcolumns (see
buglist.cgi around line 503) when the output format is "ics". We should probably
go ahead and enforce the other columns we require if they're not already in
@selectcolumns now.

Comment 48

[Vlad Dascalu]

Comment on attachment 143339 [details] [diff] [review]
updated patch with an ics filter

Canceling my review per comment #46.

Comment 49

[William Jon McCann]

(In reply to comment #47)
> As a hint, what we need to do (to include DTSTART in all bugs output in ICS
> format) is ensure bug.opendate will be available to the template; this involves
> changing buglist.cgi to enforce "opendate" to be present in @selectcolumns (see
> buglist.cgi around line 503) when the output format is "ics". We should probably
> go ahead and enforce the other columns we require if they're not already in
> @selectcolumns now.

My first patch actually did this.  The problem is that opendate is formatted by
DiffDate().  So, I removed it in later versions.  I think we want something that
will end up looking like (since we don't need the time component):

DTSTART;VALUE=DATE:19970317

What is the best way to do this?  We could put an ICS condition in DiffDate,
create a new function to format the origdate when the output is ICS, or pass the
database output directly and format it in the ICS template.

Comment 50

[William Jon McCann]

(In reply to comment #45)
> Please try it with ical, and you will note not a single entry will be imported
> properly.

Odd, it still works for me when I subscribe to it.  However, I think that by
default iCal does not "import" TODO items.  Here is what I do:

- Select the Calendar/Subscribe menu item.
- Un-select the "Remove To Do items" checkbox.
- Paste the URL to your bugs.ics attachment into the Calendar URL field
- Click Subscribe

Anyway, DTSTART certainly is useful and if it helps at all we should try to get
it in there.

Comment 51

[Dave Miller [:justdave]]

Doh, that's ingenious, subscribing to it. :)  Wonder how much load that puts on
the server with it running that query repetatively though...  (how often does
iCal check a subscribed calendar?)

I think what the rest of us have been doing is just clicking the link and
letting the browser open the resulting file in iCal after the download.

Comment 52

[Dave Miller [:justdave]]

Also, I'm pretty sure we override the date formatting for CSV...  we should do
the same for iCal.

Comment 53

[William Jon McCann]

Attachment: updated patch with dates

Updated patch to:

- always include DTSTART 
- always include DTSTAMP (from sec. 4.8.7.2 of spec)
- include LAST-MODIFIED when bug.changeddate is selected
- include PERCENT-COMPLETE when bug.percentage_complete is available
- add ics filter to tests

Comment 54

[Vlad Dascalu]

Comment on attachment 143743 [details] [diff] [review]
updated patch with dates

This patch doesn't apply cleanly to the tip. You should do a "cvs update"
before diffing. When applying, there is only one fatal error in 008filter.t,
which is easy to fix (the others are succeeded hunks with a small offset):

patch -p0 < /home/vladd/bz-ics.patch

patching file buglist.cgi
Hunk #2 succeeded at 527 (offset 8 lines).
Hunk #3 succeeded at 717 (offset 8 lines).
Hunk #4 succeeded at 818 (offset 8 lines).
patching file Bugzilla/Constants.pm
patching file Bugzilla/Template.pm
Hunk #1 succeeded at 293 (offset 35 lines).
patching file t/008filter.t
Hunk #1 FAILED at 198.
1 out of 1 hunk FAILED -- saving rejects to file t/008filter.t.rej
patching file template/en/default/list/list.html.tmpl
Hunk #1 succeeded at 139 with fuzz 1 (offset -10 lines).
patching file template/en/default/list/list.ics.tmpl

> +sub iCalendarDateTime {

I guess it would be nice to have and use an unique function across bugzilla for
that conversion. However, grepping the source for "str2time" and "sprintf"
shows several instances of this, and since standardization isn't already
present, I think we can safety leave that for another bug.

-    return 1 if $directive =~ /FILTER\ (html|csv|js|url_quote|css_class_quote|
+    return 1 if $directive =~ /FILTER\
(html|csv|ics|js|url_quote|css_class_quote|

Nitpick: your addition here makes that line longer than 80 chars. You could
make it shorter in order not to be splited.

>+[%+ bug.keywords FILTER ics('X-BUGZILLA-KEYWORDS') +%]
>+[% END %]
>+END:VTODO
>+[% END %]

Is there some reason for which we don't use Template Toolkit identation here (2
spaces)?

Comment 55

[William Jon McCann]

Attachment: updated patch for HEAD

Sorry about that.  I was doing a cvs update but not "cvs update -dP -A" and so
I was producing patches for the 2.17.6 branch.

- changed indentation in BLOCK from 4 to 2 spaces
- moved ics addition in 008filter.t to next line (so not to exceed 80 chars)

In response to comment:
I can't put spaces in the ics template outside of the BLOCKs because they will
show up in the output and aren't allowed by the RFC.  Inside the BLOCKs spaces
are allowed because TRIM is set to 1.

Comment 56

[Dave Miller [:justdave]]

a= justdave
resolve the bug when the code is checked in.  documentation+ when the docs are
checked in (section 5.5)

Comment 57

[Vlad Dascalu]

Checking in buglist.cgi;
/cvsroot/mozilla/webtools/bugzilla/buglist.cgi,v  <--  buglist.cgi
new revision: 1.247; previous revision: 1.246
done
Checking in Bugzilla/Constants.pm;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/Constants.pm,v  <--  Constants.pm
new revision: 1.8; previous revision: 1.7
done
Checking in Bugzilla/Template.pm;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/Template.pm,v  <--  Template.pm
new revision: 1.16; previous revision: 1.15
done
Checking in t/008filter.t;
/cvsroot/mozilla/webtools/bugzilla/t/008filter.t,v  <--  008filter.t
new revision: 1.10; previous revision: 1.9
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.25; previous revision: 1.24
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.3; previous revision: 1.2
done

Thanks William!

Comment 58

[A. Karl Kornel]

Attachment: Docs for 2.18 v1

documentation@: I already see a mention of this in the tip docs at
<http://www.bugzilla.org/docs/tip/html/list.html>.  However, there is no
mention in the docs for 2.18 at
<http://www.bugzilla.org/docs/2.18/html/list.html>.

I'm submitting a docs patch for 2.18, diffed against BUGZILLA-2_18-BRANCH,
requesting review, and suggest that the documentation flag be set to + as
appropriate docs in tip are already in place.

Comment 59

[Colin Ogilvie [:cso]]

Comment on attachment 188976 [details] [diff] [review]
Docs for 2.18 v1

Theres a typo in this, ingo -> into and I also wonder why you don't use the
same documentation as the tip says...

Comment 60

[A. Karl Kornel]

Attachment: Docs for 2.18 v2

Modification of attachment 188976 [details] [diff] [review], taking into account comment 59.  Requesting
review from documentation@.

(In reply to comment #59)
> Theres a typo in this, ingo -> into and I also wonder why you don't use the
> same documentation as the tip says...

No idea.

Again, I suggest that documentation? be set to + as docs already seem to be in
place for tip/2.20.

Comment 61

[Colin Ogilvie [:cso]]

Comment on attachment 191930 [details] [diff] [review]
Docs for 2.18 v2

r=me, by inspection

Comment 62

[A. Karl Kornel]

Who handles checkin for the docs patch?

Comment 63

[Frédéric Buclin]

2.18.5:

Checking in docs/xml/using.xml;
/cvsroot/mozilla/webtools/bugzilla/docs/xml/using.xml,v  <--  using.xml
new revision: 1.21.2.6; previous revision: 1.21.2.5
done