Serialize avatar URL in user resource only when URLs available
Review Request #9457 — Created Dec. 19, 2017 and submitted
Previously we assumed that all avatar services would return URLs.
However, it is possible that the service has yet to be configured for a
user (e.g., they haven't uploaded an avatar yet for the
FileUploadAvatarService
) or the avatar service returns bad data. In
these cases, we now wrap the serialization in atry..except
to ensure
that we don't cause exceptions that crash the resource.Additionally, we also ensure that we serialize the
avatar_urls
field
as{}
instead ofNone
when there are no URLs to simplify
deserialization logic.
Ran unit tests.
Description | From | Last Updated |
---|---|---|
Can you update the description to also mention the change to the avatar_urls field? That'll make it easier to remember … |
chipx86 | |
This whole thing could be just return urls and urls.get('1x') |
david | |
Single quotes. |
david | |
Maybe worth having this return {} when there are no URLs? Simplifies the above code, simplifies clients who no longer … |
chipx86 | |
Plurals are wrong here. "avatar service"? |
chipx86 |
-
-
reviewboard/webapi/resources/user.py (Diff revision 1) This whole thing could be just
return urls and urls.get('1x')
-
Change Summary:
Addressed David's issues.
Commit: |
|
||||
---|---|---|---|---|---|
Diff: |
Revision 2 (+36 -7) |
Checks run (2 succeeded)
Change Summary:
Dont return {} from no urls
Commit: |
|
||||
---|---|---|---|---|---|
Diff: |
Revision 3 (+37 -4) |
Checks run (2 succeeded)
-
-
reviewboard/webapi/resources/user.py (Diff revision 3) Maybe worth having this return
{}
when there are no URLs? Simplifies the above code, simplifies clients who no longer need to check fornull
but can instead just check for the presence of certain avatars (or check falsiness). -
Change Summary:
Addressed Christian's issues.
Commit: |
|
||||
---|---|---|---|---|---|
Diff: |
Revision 4 (+38 -5) |
Checks run (2 succeeded)
Change Summary:
Addressed Christian's issue.
Description: |
|
---|