916958 - Ember.show API returns user-related information inconsistently

Status: RESOLVED FIXED

(bugzilla.mozilla.org :: API, defect)

Description

[Erik Bryn]

For example: https://bugzilla-dev.allizom.org/rest/ember/show/843868

In attachments, `attacher` and `creator` are email addresses (regardless of authentication, which seems like a bug). The `setter` field of the first attachment's flag is an object which contains, based on whether you're authenticated, either `real_name` or both `real_name` and `email`.

Comments also have `author` and `creator` fields which are email addresses (again regardless of authentication, which seems like a bug).

Bugs have a `creator` field, which will be an email address (regardless of authentication). There may be other occurrences as well.

It would be nice if we could have a consistent pattern when we're exposing users in API responses.

Comment 1

[:glob ✱]

i totally agree with both of these requests - stop returning full email addresses and consistency across returned objects - however both would break compatibility with existing api consumers :(

my recommendation is for both of these issues to be addressed when we rework upstream bugzilla's REST api - then we can design and document how each object is to be returned regardless of context.

Comment 2

[Erik Bryn]

We could fix this in the Ember extension, right?

Comment 3

[:glob ✱]

(In reply to Erik Bryn from comment #2)
> We could fix this in the Ember extension, right?

it's technically possible, but would require some effort and time.
the ember ext is a thin shim over the native results - it doesn't construct responses from scratch.

Comment 4

[David Lawrence [:dkl]]

(In reply to Erik Bryn from comment #0)
> For example: https://bugzilla-dev.allizom.org/rest/ember/show/843868
> 
> In attachments, `attacher` and `creator` are email addresses (regardless of
> authentication, which seems like a bug). 

There is functionality in the webservice code to filter the email address based on whether the client is authenticated or not. Currently BMO this parameter turned off (webservice_filter_email). Glob, any issue with turning that on? LpSolit asked about it the other day as well.

> The `setter` field of the first
> attachment's flag is an object which contains, based on whether you're
> authenticated, either `real_name` or both `real_name` and `email`.
> 
> Comments also have `author` and `creator` fields which are email addresses
> (again regardless of authentication, which seems like a bug).
> Bugs have a `creator` field, which will be an email address (regardless of
> authentication). There may be other occurrences as well.
> 
> It would be nice if we could have a consistent pattern when we're exposing
> users in API responses.

As glob mentioned this will all be ironed out in the coming quarter or two when we initiate the BzAPI compat layer and then push the changes upstream little by little. I too want this to be more consistent and REST like. I can see what we can do with the Ember code to help out some here but as glob said it might not be a trivial amount of work.

dkl

Comment 5

[:glob ✱]

(In reply to David Lawrence [:dkl] from comment #4)
> There is functionality in the webservice code to filter the email address
> based on whether the client is authenticated or not. Currently BMO this
> parameter turned off (webservice_filter_email). Glob, any issue with turning
> that on? LpSolit asked about it the other day as well.

yes - that is a compatibility breaking change.
i think the right time to flip that is when we upgrade to 4.4.

Comment 6

[David Lawrence [:dkl]]

Also fwiw, we are closer to landing a patch in bug 916254 that adds extra information for assignee, qa contact, and reporter into the data returned by Bug.get. So once that lands I will port it over and we can use that as well.

dkl

Comment 7

[David Lawrence [:dkl]]

(In reply to David Lawrence [:dkl] from comment #6)
> Also fwiw, we are closer to landing a patch in bug 916254 that adds extra
> information for assignee, qa contact, and reporter into the data returned by
> Bug.get. So once that lands I will port it over and we can use that as well.
> 
> dkl

This has been live as of http://bzr.mozilla.org/bmo/4.2/revision/9084 so please use
the new *_detail fields for the extended information. 

dkl