171478 - XML bug output should include attachment flags

Status: RESOLVED FIXED

(Bugzilla :: Attachments & Requests, enhancement)

Description

[Bradley Baetz (:bbaetz)]

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)

Comment 1

[Christopher Aillon (sabbatical, not receiving bugmail)]

I need this for something I'm working on.  Taking.

Comment 2

[Christopher Aillon (sabbatical, not receiving bugmail)]

Attachment: 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.

Comment 3

[Christian Reis]

Comment on attachment 135684 [details] [diff] [review]
Include attachment flags

I've tried my best to nitpick, but nothing exciting hit me. r=kiko

Comment 4

[Christopher Aillon (sabbatical, not receiving bugmail)]

Looking for approval.  very trivial fix to a somewhat obscure file.

Comment 5

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

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.

Comment 6

[Vlad Dascalu]

Canceling approval pending a new patch.

Comment 7

[Jaros³aw Kutylowski]

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.

Comment 8

[Ravenous Bugblatter Beast]

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?

Comment 9

[Colin Ogilvie [:cso]]

Attachment: Patch v2

Fixes Myk's review comments from the patch in 2003 - otherwise, this is the
same as the original patch.

Comment 10

[Marc Schumann [:Wurblzap]]

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.

Comment 11

[Colin Ogilvie [:cso]]

(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.

Comment 12

[Colin Ogilvie [:cso]]

Attachment: Patch v3

Fixes issues from Review

Comment 13

[Vlad Dascalu]

Targeting bug to 2.20 since the 2.20 feature freeze was canceled.

Comment 14

[Vlad Dascalu]

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