Closed
Bug 235459
Opened 21 years ago
Closed 21 years ago
add icalendar todo output format for buglist
Categories
(Bugzilla :: Query/Bug List, enhancement)
Tracking
()
RESOLVED
FIXED
Bugzilla 2.18
People
(Reporter: william.jon.mccann, Assigned: william.jon.mccann)
References
()
Details
Attachments
(3 files, 11 obsolete files)
85.37 KB,
text/calendar
|
Details | |
9.01 KB,
patch
|
goobix
:
review+
|
Details | Diff | Splinter Review |
679 bytes,
patch
|
cso
:
review+
|
Details | Diff | Splinter Review |
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•21 years ago
|
||
Assignee | ||
Comment 2•21 years ago
|
||
Assignee | ||
Comment 3•21 years ago
|
||
Comment 4•21 years ago
|
||
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...
Updated•21 years ago
|
Attachment #142153 -
Attachment is obsolete: true
Attachment #142154 -
Attachment is obsolete: true
Attachment #142155 -
Attachment is obsolete: true
Updated•21 years ago
|
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
Comment 5•21 years ago
|
||
The attached URL is the RFC specifying this file format.
Assignee | ||
Comment 6•21 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
Comment 7•21 years ago
|
||
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•21 years ago
|
||
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•21 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•21 years ago
|
||
vlad: Thanks for the help.
Attachment #142289 -
Attachment is obsolete: true
Comment 11•21 years ago
|
||
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•21 years ago
|
||
+ 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•21 years ago
|
Attachment #142346 -
Attachment is obsolete: true
Comment 13•21 years ago
|
||
Comment on attachment 142379 [details] [diff] [review]
updated patch
r= justdave
Attachment #142379 -
Flags: review+
Comment 14•21 years ago
|
||
The most-recent patch is live on http://landfill.bugzilla.org/bzdave/ again.
(Dunno how long it'll stay there ;)
Flags: approval+
Comment 15•21 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
Closed: 21 years ago
Resolution: --- → FIXED
Comment 16•21 years ago
|
||
Tree's on fire due to the checkin.
Comment 17•21 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•21 years ago
|
||
Comment 19•21 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•21 years ago
|
||
Section 4.7 in the RFC describes each fieldtype, checking to see what's appropriate.
Comment 21•21 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•21 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•21 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•21 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•21 years ago
|
||
Comment on attachment 142158 [details] [diff] [review]
Combined patch
This is obsolete as well AFAIK.
Attachment #142158 -
Attachment is obsolete: true
Comment 26•21 years ago
|
||
<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•21 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
Comment 28•21 years ago
|
||
> <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•21 years ago
|
||
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•21 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•21 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•21 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 33•21 years ago
|
||
Attachment #142379 -
Flags: review+ → review-
Comment 34•21 years ago
|
||
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•21 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•21 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•21 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•21 years ago
|
||
Assignee | ||
Updated•21 years ago
|
Attachment #142379 -
Attachment is obsolete: true
Comment 39•21 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•21 years ago
|
Attachment #143339 -
Flags: review?
Comment 40•21 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•21 years ago
|
Flags: approval?
Comment 41•21 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•21 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•21 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•21 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•21 years ago
|
||
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•21 years ago
|
||
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•21 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.
Updated•21 years ago
|
Flags: approval?
Comment 48•21 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•21 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•21 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.
Comment 51•21 years ago
|
||
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•21 years ago
|
||
Also, I'm pretty sure we override the date formatting for CSV... we should do
the same for iCal.
Assignee | ||
Comment 53•21 years ago
|
||
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•21 years ago
|
Attachment #143339 -
Attachment is obsolete: true
Comment 54•21 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•21 years ago
|
||
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•21 years ago
|
Attachment #143812 -
Flags: review+
Updated•21 years ago
|
Flags: approval?
Comment 56•21 years ago
|
||
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•21 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
Closed: 21 years ago → 21 years ago
Resolution: --- → FIXED
Updated•21 years ago
|
Flags: documentation2.18?
Comment 58•20 years ago
|
||
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•20 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•20 years ago
|
||
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•20 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•20 years ago
|
||
Who handles checkin for the docs patch?
![]() |
||
Comment 63•19 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+
Updated•12 years ago
|
QA Contact: matty_is_a_geek → default-qa
You need to log in
before you can comment on or make changes to this bug.
Description
•