-
Notifications
You must be signed in to change notification settings - Fork 3.9k
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 optional field 'is_enrolled' to course detail view #33646
feat: [FC-0031] Add optional field 'is_enrolled' to course detail view #33646
Conversation
Thanks for the pull request, @GlugovGrGlib! 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. |
""" | ||
response = super().to_representation(instance) | ||
if can_show_certificate_available_date_field(instance): | ||
response['certificate_available_date'] = instance.certificate_available_date | ||
|
||
requested_user = self.context['request'].query_params.get('username', None) | ||
if self.context['request'].user.is_authenticated and requested_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.
This would let any user look up the enrollment status for any other user, I think we would only want to allow that if the user is a staff
user and otherwise, we should only provide this info in the requested user is the same as the authenticated user.
Alternatively, we could just flag this on if an authenticated user is making the call and provide the authenticated users enrollment status in that case. This might be simpler?
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.
@feanil The code was updated to follow proposed logic, please review
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.
Agreed with comments above, the approach LGTM.
d2cab9a
to
b3e0aea
Compare
@feanil I believe your comments have been addressed. |
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.
Updates to the API look great, but I had a question about some other files that got added. If we can drop those, I think the rest of this is good to merge.
cms/envs/devstack_docker.py
Outdated
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.
Why was this added to the PR? is this a mistake? This file is nearly empty because we're trying to get rid of it so if there is a reason for these override, I'd like to understand it so I can help find a better place for the overrides.
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, sorry, this is mistake happened during rebase, will update this, thanks
lms/envs/devstack_docker.py
Outdated
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.
Same question here as in the other settings file:
Why was this added to the PR? is this a mistake? This file is nearly empty because we're trying to get rid of it so if there is a reason for these override, I'd like to understand it so I can help find a better place for the overrides.
if requested_username: | ||
user = self.context['request'].user | ||
if ((user.is_authenticated and user.username == requested_username) | ||
or user.is_staff): |
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.
One more thing: I think this should also be allowed for is_superuser
users. Can you add that as well?
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, is_superuser status should be allowed to do this as well, thanks
b3e0aea
to
d344a7e
Compare
@GlugovGrGlib 🎉 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. |
Description
In this PR, the
is_enrolled
parameter is included in theCourseDetailView
endpoint's response when the optionalusername
query parameter is provided.Supporting information
This contribution is a part of the FC-0031
Testing instructions
GET /api/mobile/v3/course_info/{course_key}/info
See that "is_enrolled" is present in the response
Other information
The rejected implementation for the mobile endpoint can be found in #33297