Value of creator incorrect - Answer API

RESOLVED FIXED in 2014Q4

Status

support.mozilla.org
BuddyUp
P1
normal
RESOLVED FIXED
3 years ago
3 years ago

People

(Reporter: espressive, Assigned: mythmon)

Tracking

unspecified
2014Q4
All
Gonk (Firefox OS)

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: u=dev c=buddyup p=1 s=2014.21)

(Reporter)

Description

3 years ago
For the answer API - https://support.allizom.org/api/2/answer/ - the value of the creator property should be equal to the user's display name and not username.
(Assignee)

Comment 1

3 years ago
I don't think this is right. The creator field is a foreign key into the users table. The API reflects this by providing the primary key for that table (the globally unique username). Display names are not globally unique, and so using this value for the field would make it impossible to correctly identify answers belonging to a user using the API.

The creator field may become a "nested" field and include more information about the user, such as:

GET /api/2/answer/1234/

{
  "id": 1234,
  ...
  "creator": {
    "username": "bob",
    "display_name": "bobert the 3rd",
    ...
  }
}

Would that be ok? This would be a break from how things have been done so far, and complicate the filtering code. Additionally, this change would have to take place across the entire API.
(Reporter)

Comment 2

3 years ago
(In reply to Mike Cooper [:mythmon] from comment #1)
> The creator field may become a "nested" field and include more information
> about the user, such as:
> 
> GET /api/2/answer/1234/
> 
> {
>   "id": 1234,
>   ...
>   "creator": {
>     "username": "bob",
>     "display_name": "bobert the 3rd",
>     ...
>   }
> }
> 
> Would that be ok?

That would be fine, although I note the caveats. Basically as long as we can get to the display name of the user that posted the question (without having to make another call to the server), we are all good.

Of course if the user's display name is empty, we need to fallback to the username still so, we actually need access to both here.

Probably does not fit the model, not sure but, could you expose an additional field entitled creator_display_name (just display_name) or something along those lines?
Deployed to prod:
https://github.com/mozilla/kitsune/commit/4b2a23c876c666dcbd5cf89d6c41435278616ad3
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → 2014Q4
sprint bits
Whiteboard: u=dev c=buddyup p=1 s=2014.21
You need to log in before you can comment on or make changes to this bug.