Closed Bug 1156240 Opened 9 years ago Closed 9 years ago

Return proper "See Also" data on REST API call to a bug

Categories

(Bugzilla :: WebService, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
Bugzilla 6.0

People

(Reporter: mva, Assigned: mva)

References

Details

(Keywords: regression)

Attachments

(1 file)

User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0
Build ID: 20150402191859

Steps to reproduce:

Query a bug via REST, which has one or more "See Also" URLs configured (e.g. localhost:8080/rest/bug/1)




Actual results:

The JSON result will look like 
...
  "see_also" : [
       "Bugzilla::BugUrl::ARRAY(0x12345)"
  ],


Expected results:

A proper URL should have been returned (find a fix attached).
Attachment #8594710 - Attachment is patch: true
Attachment #8594710 - Attachment mime type: text/x-patch → text/plain
Version: 5.0 → 5.1
Attachment #8594710 - Flags: review?(dkl)
Comment on attachment 8594710 [details] [diff] [review]
rest_seealso.diff

Review of attachment 8594710 [details] [diff] [review]:
-----------------------------------------------------------------

r=dkl
Attachment #8594710 - Flags: review?(dkl) → review+
Flags: approval?
Assignee: webservice → mva
Status: UNCONFIRMED → ASSIGNED
Depends on: 1051056
Ever confirmed: true
Keywords: regression
Summary: Bugfix: Return proper "See Also" data on REST API call to a bug → Return proper "See Also" data on REST API call to a bug
Target Milestone: --- → Bugzilla 6.0
I do not see the point of moving that change to release 6.0.

The see_also value is unusable in 5.0+ at the moment, so it does not provide any useful value and thus does not break any compatibility.
And while here, I wonder, why I became the assignee - I can't fix the bug, since I do not have commit access to the repo and thus cannot fix the issue. What is the intended bug workflow here?
(In reply to mva from comment #2)
> I do not see the point of moving that change to release 6.0.
> 
> The see_also value is unusable in 5.0+ at the moment, so it does not provide
> any useful value and thus does not break any compatibility.

It is only broken in 5.1 and above so it will be in the next release (probably 6.0). 5.0 does not have the refactored WebService API that was recently checked into trunk so it doesn't have this regression.

(In reply to mva from comment #3)
> And while here, I wonder, why I became the assignee - I can't fix the bug,
> since I do not have commit access to the repo and thus cannot fix the issue.
> What is the intended bug workflow here?

You are set to the assignee since you submitted a patch for review. When we check it in (probably me as the reviewer) the commit will get you set as the author of the patch in the git repo.

dkl
Flags: approval? → approval+
To ssh://gitolite3@git.mozilla.org/bugzilla/bugzilla.git
   1f981e1..6f88fd0  master -> master
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
mva - thank you for the patch! :-)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: