928410 - Bug.get should return detail about cc list members similar to assigned_to, creator and qa_contact

Status: RESOLVED FIXED

(Bugzilla :: WebService, enhancement)

Description

[David Lawrence [:dkl]]

Currently when returning data from Bug.get, you can get extra details about the assignee, reporter, and qa contact. But not for members of the cc list. Patch coming that will also add 'cc_detail' for the cc list members.

dkl

Comment 1

[David Lawrence [:dkl]]

Attachment: 928410_1.patch

Comment 2

[David Lawrence [:dkl]]

Comment on attachment 819044 [details] [diff] [review]
928410_1.patch

Gerv has less reviews and this one should be short.

Comment 3

[Gervase Markham [:gerv]]

Comment on attachment 819044 [details] [diff] [review]
928410_1.patch

dkl: this seems like a bit of a hack; are you doing it this way rather than updating the "cc" item to be a hash because of backwards compatibility?

Can we change the contents of "cc" in the next major-numbered release of Bugzilla (5.0), do your change for now, but use documentation to encourage people to write code which checks for both cases?

Gerv

Comment 4

[David Lawrence [:dkl]]

(In reply to Gervase Markham [:gerv] from comment #3)
> Comment on attachment 819044 [details] [diff] [review]
> 928410_1.patch
> 
> dkl: this seems like a bit of a hack; are you doing it this way rather than
> updating the "cc" item to be a hash because of backwards compatibility?
> 
> Can we change the contents of "cc" in the next major-numbered release of
> Bugzilla (5.0), do your change for now, but use documentation to encourage
> people to write code which checks for both cases?
> 
> Gerv

We cannot change the contents of 'cc' as long as Bug.get is marked as STABLE even when we go to 5.0. We can only
add additional keys such as *_detail. Of course when we support versioning of the API, REST 2.0 will have cc, assigned_to, qa_contact, creator, etc. be replaced by their _detail counterparts. I would rather do that method
than change a stable method as Bugzilla versions and API versions should be different.

dkl

Comment 5

[Gervase Markham [:gerv]]

(In reply to David Lawrence [:dkl] from comment #4)
> We cannot change the contents of 'cc' as long as Bug.get is marked as STABLE
> even when we go to 5.0. 

From http://www.bugzilla.org/docs/4.2/en/html/api/Bugzilla/WebService.html:

"If we ever break a STABLE interface, we'll post a big notice in the Release Notes, and it will only happen during a major new release."

So I think we can.

> Of course when we support versioning
> of the API, REST 2.0 will have cc, assigned_to, qa_contact, creator, etc. be
> replaced by their _detail counterparts.

That would lead to a divergence between REST and XML-RPC (unless you are proposing to version XML-RPC as well?). Are you cool with that?

Gerv

Comment 6

[David Lawrence [:dkl]]

(In reply to Gervase Markham [:gerv] from comment #5)
> (In reply to David Lawrence [:dkl] from comment #4)
> > We cannot change the contents of 'cc' as long as Bug.get is marked as STABLE
> > even when we go to 5.0. 
> 
> From http://www.bugzilla.org/docs/4.2/en/html/api/Bugzilla/WebService.html:
> 
> "If we ever break a STABLE interface, we'll post a big notice in the Release
> Notes, and it will only happen during a major new release."
> 
> So I think we can.
> 

The original thinking was:

1) For 5.0+ we would make REST the primary API and XMLRPC/JSONRPC would be carried along and only security fixes would be added.
2) After 6.0+, XMLRPC/JSONRPC to be removed completely and all work to be on REST only.

After some discussion it could be that we just do 1) as a 4.6 release and then do 2) for 5.0 when it comes out and speed things along soon. 

Both scenarios would hinge on getting versioning to work and we would brand what we have now as 1.0 and then 1.1 of the REST API we can start making incremental changes where it makes sense.

> > Of course when we support versioning
> > of the API, REST 2.0 will have cc, assigned_to, qa_contact, creator, etc. be
> > replaced by their _detail counterparts.
> 
> That would lead to a divergence between REST and XML-RPC (unless you are
> proposing to version XML-RPC as well?). Are you cool with that?

We would never version the XMLRPC/JSONRPC APIs, only REST.

dkl

Comment 7

[Gervase Markham [:gerv]]

Comment on attachment 819044 [details] [diff] [review]
928410_1.patch

OK. r=gerv.

Gerv

Comment 8

[David Lawrence [:dkl]]

Committing to: bzr+ssh://[e-mail]/bugzilla/trunk
modified Bugzilla/WebService/Bug.pm
Committed revision 8788.