add icalendar todo output format for buglist

RESOLVED FIXED in Bugzilla 2.18

Status

()

Bugzilla
Query/Bug List
--
enhancement
RESOLVED FIXED
14 years ago
5 years ago

People

(Reporter: William Jon McCann, Assigned: William Jon McCann)

Tracking

2.17.6
Bugzilla 2.18
Bug Flags:
approval +
documentation +
documentation2.18 +

Details

(URL)

Attachments

(3 attachments, 11 obsolete attachments)

85.37 KB, text/calendar
Details
9.01 KB, patch
Vlad Dascalu
: review+
Details | Diff | Splinter Review
679 bytes, patch
cso
: review+
Details | Diff | Splinter Review
(Assignee)

Description

14 years ago
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.
(Assignee)

Comment 1

14 years ago
Created attachment 142153 [details]
new file for template/en/default/list
(Assignee)

Comment 2

14 years ago
Created attachment 142154 [details] [diff] [review]
patch to add mime type and add origdate to selected fields
(Assignee)

Comment 3

14 years ago
Created attachment 142155 [details] [diff] [review]
patch to add download option to default bug list template
Created attachment 142158 [details] [diff] [review]
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...
Attachment #142153 - Attachment is obsolete: true
Attachment #142154 - Attachment is obsolete: true
Attachment #142155 - Attachment is obsolete: true
Assignee: justdave → mccannwj
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
Hardware: PC → All
Target Milestone: --- → Bugzilla 2.18
Version: unspecified → 2.17.6
The attached URL is the RFC specifying this file format.
(Assignee)

Comment 6

14 years ago
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
Status: NEW → ASSIGNED
Summary: add ical todo output format for buglist → add icalendar todo output format for buglist
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
(Assignee)

Comment 8

14 years ago
Created attachment 142289 [details]
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

14 years ago
> 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.
(Assignee)

Comment 10

14 years ago
Created attachment 142346 [details] [diff] [review]
combined patch

vlad: Thanks for the help.
Attachment #142289 - Attachment is obsolete: true
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
Attachment #142346 - Flags: review+
(Assignee)

Comment 12

14 years ago
Created attachment 142379 [details] [diff] [review]
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.
(Assignee)

Updated

14 years ago
Attachment #142346 - Attachment is obsolete: true
Comment on attachment 142379 [details] [diff] [review]
updated patch

r= justdave
Attachment #142379 - Flags: review+
The most-recent patch is live on http://landfill.bugzilla.org/bzdave/ again. 
(Dunno how long it'll stay there ;)
Flags: approval+

Comment 15

14 years ago
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
Status: ASSIGNED → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED

Comment 16

14 years ago
Tree's on fire due to the checkin.

Comment 17

14 years ago
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

14 years ago
Created attachment 142594 [details] [diff] [review]
Restoring tree to green patch

Comment 19

14 years ago
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

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

Comment 21

14 years ago
<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

14 years ago
<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
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Comment 23

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

This is not quite the right thing.
Attachment #142594 - Attachment is obsolete: true

Comment 24

14 years ago
Clearing the a+ flag in order to get this off the radar regarding the "Ready to
checkin" query.
Status: REOPENED → ASSIGNED
Flags: approval+

Comment 25

14 years ago
Comment on attachment 142158 [details] [diff] [review]
Combined patch

This is obsolete as well AFAIK.
Attachment #142158 - Attachment is obsolete: true
<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

14 years ago
>> 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
> <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
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

14 years ago
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.
Flags: approval?
(Assignee)

Comment 31

14 years ago
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

14 years ago
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 on attachment 142379 [details] [diff] [review]
updated patch

r- based on comment 32...
Attachment #142379 - Flags: review+ → review-
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)
Flags: approval?

Comment 35

14 years ago
(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

14 years ago
(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?
(Assignee)

Comment 37

14 years ago
(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.
(Assignee)

Comment 38

14 years ago
Created attachment 143339 [details] [diff] [review]
updated patch with an ics filter
(Assignee)

Updated

14 years ago
Attachment #142379 - Attachment is obsolete: true

Comment 39

14 years ago
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.

Updated

14 years ago
Attachment #143339 - Flags: review?

Comment 40

14 years ago
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.
Attachment #143339 - Flags: review? → review+

Updated

14 years ago
Flags: approval?

Comment 41

14 years ago
(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

14 years ago
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.
(Assignee)

Comment 43

14 years ago
(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

14 years ago
(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

14 years ago
Created attachment 143682 [details]
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 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.
Attachment #143339 - Flags: review-

Comment 47

14 years ago
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.
Flags: approval?

Comment 48

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

Canceling my review per comment #46.
Attachment #143339 - Flags: review+
(Assignee)

Comment 49

14 years ago
(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.
(Assignee)

Comment 50

14 years ago
(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.
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.
Also, I'm pretty sure we override the date formatting for CSV...  we should do
the same for iCal.
(Assignee)

Comment 53

14 years ago
Created attachment 143743 [details] [diff] [review]
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
(Assignee)

Updated

14 years ago
Attachment #143339 - Attachment is obsolete: true

Comment 54

14 years ago
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)?
Attachment #143743 - Flags: review-
(Assignee)

Comment 55

14 years ago
Created attachment 143812 [details] [diff] [review]
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.
Attachment #143743 - Attachment is obsolete: true

Updated

14 years ago
Attachment #143812 - Flags: review+

Updated

14 years ago
Flags: approval?
a= justdave
resolve the bug when the code is checked in.  documentation+ when the docs are
checked in (section 5.5)
Flags: documentation?
Flags: approval?
Flags: approval+

Comment 57

14 years ago
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!
Status: ASSIGNED → RESOLVED
Last Resolved: 14 years ago14 years ago
Resolution: --- → FIXED
Flags: documentation2.18?

Updated

13 years ago
Blocks: 284425

Comment 58

13 years ago
Created attachment 188976 [details] [diff] [review]
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.
Attachment #188976 - Flags: review?(documentation)

Comment 59

13 years ago
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...
Attachment #188976 - Flags: review?(documentation) → review-

Comment 60

13 years ago
Created attachment 191930 [details] [diff] [review]
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.
Attachment #188976 - Attachment is obsolete: true
Attachment #191930 - Flags: review?(documentation)

Comment 61

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

r=me, by inspection
Attachment #191930 - Flags: review?(documentation) → review+

Comment 62

13 years ago
Who handles checkin for the docs patch?

Comment 63

12 years ago
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
Flags: documentation?
Flags: documentation2.18?
Flags: documentation2.18+
Flags: documentation+
QA Contact: matty_is_a_geek → default-qa
You need to log in before you can comment on or make changes to this bug.