The xml bug output doesn't include bug or attachment flags. It should. I'm probably going to fix the bug part as part of the 'remove bug_form.pl' bug (or at least the Bug.pm bits)
I need this for something I'm working on. Taking.
Assignee: myk → caillon
Status: NEW → ASSIGNED
Created attachment 135684 [details] [diff] [review] Include attachment flags Bug flags will require some more work, since they are slightly more complicated, but I'd like to at least get this into the tree.
Attachment #135684 - Flags: review?(bbaetz)
Comment on attachment 135684 [details] [diff] [review] Include attachment flags I've tried my best to nitpick, but nothing exciting hit me. r=kiko
Attachment #135684 - Flags: review?(bbaetz) → review+
Looking for approval. very trivial fix to a somewhat obscure file.
Attachment #135684 - Flags: review?(myk)
Comment on attachment 135684 [details] [diff] [review] Include attachment flags >Index: template/en/default/bug/show.xml.tmpl >+ <type>[% IF a.ispatch; >+ "patch"; >+ ELSE; >+ a.contenttype FILTER xml; >+ END; >+ %]</type> We use ctype in other places to abbreviate content type, and we should use it here too. "type" by itself is too ambiguous. Also, patches should be text/plain with an "ispatch" attribute to flag them as patches; it's consistent with how we do it elsewhere in Bugzilla, and it means a client that doesn't care whether the attachment is a patch or not doesn't have to do any special processing of the ctype value before using it as a content type.
Attachment #135684 - Flags: review?(myk) → review-
Canceling approval pending a new patch.
The xml output also does not include information about the "obsolete" parameter on attachment level. Shouldn't this be output too? The xml output should in general provide means to access all data directly connected with bugs.
The manual mentions the format returned by ctype=xml queries is used to import bugs from other systems. If this format is patched to include flags, shouldn't it also require a change to the import.pl script to import them?
Created attachment 169989 [details] [diff] [review] Patch v2 Fixes Myk's review comments from the patch in 2003 - otherwise, this is the same as the original patch.
Attachment #169989 - Flags: review?
Comment on attachment 169989 [details] [diff] [review] Patch v2 Nearly there :) +<!ATTLIST attachment + isobsolete (0|1) #IMPLIED + ispatch (0|1) #IMPLIED This tag needs to be closed. +<!ELEMENT flag> This should be <!ELEMENT flag EMPTY>, right? + status="[% flag.status %]" There's a FILTER xml missing here; runtests.pl complains.
Attachment #169989 - Flags: review? → review-
(In reply to comment #10) > +<!ATTLIST attachment > + isobsolete (0|1) #IMPLIED > + ispatch (0|1) #IMPLIED > > This tag needs to be closed. > > +<!ELEMENT flag> > > This should be <!ELEMENT flag EMPTY>, right? Odd - the XML and DTD validator I used didn't complain about such things. Time to find a new validator, I think, as they are definetly wrong.
Created attachment 170562 [details] [diff] [review] Patch v3 Fixes issues from Review
Target Milestone: --- → Bugzilla 2.22
Targeting bug to 2.20 since the 2.20 feature freeze was canceled.
Target Milestone: Bugzilla 2.22 → Bugzilla 2.20
Checking in bugzilla.dtd; /cvsroot/mozilla/webtools/bugzilla/bugzilla.dtd,v <-- bugzilla.dtd new revision: 1.10; previous revision: 1.9 done Checking in template/en/default/bug/show.xml.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/show.xml.tmpl,v <-- show.xml.tmpl new revision: 1.7; previous revision: 1.6 done
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
Summary: xml bug output should include attachment flags → XML bug output should include attachment flags
You need to log in before you can comment on or make changes to this bug.