-
Notifications
You must be signed in to change notification settings - Fork 4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: [FC-0031] Add field profile_image to CommentSerializer #33295
feat: [FC-0031] Add field profile_image to CommentSerializer #33295
Conversation
Thanks for the pull request, @oksana-slu! Please note that it may take us up to several weeks or months to complete a review and merge your PR. Feel free to add as much of the following information to the ticket as you can:
All technical communication about the code itself will be done via the GitHub pull request interface. As a reminder, our process documentation is here. Please let us know once your PR is ready for our review and all tests are green. |
ed4144b
to
dc5d225
Compare
I'm not sure either it's relevant or not but discussion APIs' are returning the user-profile data on demand when we request it by passing the additional query parameter The following API endpoints respect the query parameter specified above:
|
I see reference to "AccountLegacyProfileSerializer" and it made me wonder if we need to look at both edx-platform as this PR does and the new profile MFE, or do both rely on the same endpoints / data? In other words if the legacy edx-platform profile views are removed would we need to do anything else to have the apps still be able to request the profile image? (edit: This is for discussions, my comment was related to profile pages not discussion directly. feel free to ignore for the purpose of this PR) |
@@ -502,6 +503,7 @@ class CommentSerializer(_ContentSerializer): | |||
child_count = serializers.IntegerField(read_only=True) | |||
children = serializers.SerializerMethodField(required=False) | |||
abuse_flagged_any_user = serializers.SerializerMethodField(required=False) | |||
profile_image = serializers.SerializerMethodField(read_only=True) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As mentioned by @saeedbashir here, Can we use the requested_fields
parameters to obtain similar results in the response? The use is mentioned in code here: https://github.com/openedx/edx-platform/blob/dc5d225e920e68b7dd4526a812e60e0b808d344c/lms/djangoapps/discussion/rest_api/views.py#L798
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@oksana-slu I'm curious about your response to this, if there are specific discussion endpoints that don't support requested_fields
can we add that option to them instead? This seems more robust and better matches the other code in this API.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@moeez96 @feanil
Please confirm that we correctly understood the proposed solution.
The goal of this PR is to return profile_image
field in response to POST request to /api/discussion/v1/comments/
(When a new comment is created).
Do you propose to extend POST method of the view, so we can provide list of fields, requested_fields
in the body of the POST request, similar to GET request, and then determine what additional fields should be included in the response based on provided list?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@GlugovGrGlib I think I mis-understood, I think it's fine to include this URL though I'm concerned about the coupling/dependency to a serializer in the user_api djangoapp. I'll make a separate comment and suggestion for that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking for feedback from the author on the suggestion made regarding requested_fields
@@ -502,6 +503,7 @@ class CommentSerializer(_ContentSerializer): | |||
child_count = serializers.IntegerField(read_only=True) | |||
children = serializers.SerializerMethodField(required=False) | |||
abuse_flagged_any_user = serializers.SerializerMethodField(required=False) | |||
profile_image = serializers.SerializerMethodField(read_only=True) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@oksana-slu I'm curious about your response to this, if there are specific discussion endpoints that don't support requested_fields
can we add that option to them instead? This seems more robust and better matches the other code in this API.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Requesting some changes so that we're not reaching into the serializers of the user_api djangoapp.
@@ -502,6 +503,7 @@ class CommentSerializer(_ContentSerializer): | |||
child_count = serializers.IntegerField(read_only=True) | |||
children = serializers.SerializerMethodField(required=False) | |||
abuse_flagged_any_user = serializers.SerializerMethodField(required=False) | |||
profile_image = serializers.SerializerMethodField(read_only=True) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@GlugovGrGlib I think I mis-understood, I think it's fine to include this URL though I'm concerned about the coupling/dependency to a serializer in the user_api djangoapp. I'll make a separate comment and suggestion for that.
@@ -584,6 +586,10 @@ def get_abuse_flagged_any_user(self, obj): | |||
if _validate_privileged_access(self.context): | |||
return len(obj.get("abuse_flaggers", [])) > 0 | |||
|
|||
def get_profile_image(self, obj): | |||
request = self.context["request"] | |||
return AccountLegacyProfileSerializer.get_profile_image(request.user.profile, request.user, request) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm concerned about the coupling of serializers in the user_api djangoapp with apis in the discussions app. I think it's pretty reasonable that we want to be able to send back profile image data from multiple places so I suggest that we extract the get_profile_images
function to the api.py file in the user_api django app so it's clear that others are expected to use this and that it forms an interface that should not break.
See https://github.com/openedx/edx-platform/blob/master/docs/decisions/0002-inter-app-apis.rst for the reasoning behind this suggestion.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done. I moved get_profile_images
method to api. Now we don't use method from AccountLegacyProfileSerializer in CommentSerializer.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's make the docstring more useful. Also, this is duplicating the code from where it was previously, does it make more sense for this to just be a pass-through call to the other function. The goal of having it in api.py is to make it clear that it can and will be used externally but we don't need to duplicate the code I don't think.
""" | ||
Returns metadata about a user's profile image. | ||
""" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
""" | |
Returns metadata about a user's profile image. | |
""" | |
""" | |
Returns metadata about a user's profile image. | |
The output is a dict that looks like: | |
{ | |
"has_image": False, | |
"image_url_full": "http://testserver/static/default_500.png", | |
"image_url_large": "http://testserver/static/default_120.png", | |
"image_url_medium": "http://testserver/static/default_50.png", | |
"image_url_small": "http://testserver/static/default_30.png", | |
} | |
""" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added additional description to the docstring
ca2cf6e
to
a3d0a3e
Compare
@@ -38,7 +38,7 @@ | |||
PRIVATE_VISIBILITY, | |||
VISIBILITY_PREFIX | |||
) | |||
from .image_helpers import get_profile_image_urls_for_user |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The serializers
module gets imported a lot from the api
module already so it's leading to a circular import. I think you should extract the function to utils.py
and then call it from both the API and from the serializer to resolve the issue.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, thanks, updated code
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is still a problem with circular imports when placing the code in utils.py
, do you think the proposed implementation using AccountLegacyProfileSerializer
in api.py
is appropriate?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you mean calling the class method from api.py? I think that should be okay.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, exactly
I updated api.py and rebased branch to the latest master, please do the final review
1bcfa84
to
dbddec7
Compare
dbddec7
to
e27f674
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, I'll merge in the morning(ET) so I can keep an eye on it while it goes to edx.org and make sure we didn't miss anything.
@oksana-slu 🎉 Your pull request was merged! Please take a moment to answer a two question survey so we can improve your experience in the future. |
2U Release Notice: This PR has been deployed to the edX staging environment in preparation for a release to production. |
2U Release Notice: This PR has been deployed to the edX production environment. |
1 similar comment
2U Release Notice: This PR has been deployed to the edX production environment. |
2U Release Notice: This PR has been deployed to the edX staging environment in preparation for a release to production. |
2U Release Notice: This PR has been deployed to the edX production environment. |
2U Release Notice: This PR has been deployed to the edX production environment. |
Description
This PR extends response for POST request for creating a comment with the data about profile image. This way, it's possible to fetch an avatar image for a post or response without an additional request to a separate account settings endpoint.
Supporting information
This contribution is a part of the project FC-0031 https://openedx.atlassian.net/wiki/spaces/COMM/pages/3844505604/FC-0031+-+Mobile+API+Migration
Testing instructions
POST /api/discussion/v1/comments/ with body
{"thread_id": "put here thread id", "raw_body": "test message"}
Check that
profile_image
field present in response.