There is a bug introduced in this commit:
22046d4067 (diff-32687833c38e231b51a8f27a76c72a56R119)
The return value of the locations_to_weighted_scores[location] is
changed from `Score` object to a tuple (Score, weight). However, the
left side of assignment didn't get updated. So an error is raised and
the Celery task failed to continue. Thus, no grade is being passed back.
- Default of "desc" is all that is in use, and remains as-is.
- Discussion API keeps order_direction param, to minimize changes,
but it only accepts "desc".
- Discussion webapp simply no longer sends in the sort order.
As part of the Robust Grades rollout, we expect to see some DatabaseErrors in
various methods that write to the database. Since the success of this write
operation is not needed for the end-user, we just log and swallow the error.
In the future, we'll also enqueue an async task to finish the write operation
that failed.
The "oauth_body_hash" appeared twice in the auth header in the request
when posting grade back to tool consumer. However, the signature sent
from edX is calculated based on only one oauth_body_hash.
On the tool consumer side, the signature is calculated based on the auth
header and will use the duplicated fields. So the signatures will not match.
And request will fail the signature validation.
The bug was introduced in this commit:
03cee389e0
on July 12th by updating the oauthlib.
Because 0.7.2(original version) doesn't have oauth_body_hash support, so a custom
OAuth1 client was implemented to add oauth_body_hash to the headers:
f5d0f3ff55/lms/djangoapps/lti_provider/outcomes.py (L24).
However, the new oauthlib 1.0.3 has support for oauth_body_hash
(51675237c4 (diff-c2a1e5f1ddfe8e48ff62b59eb952644eR180)).
So after updating library, oauth_body_hash is added twice.
This fixes the bug by removing the custom client and use the oauthlib
default client to generate the auth header.
Catalog-based MicroMasters need to be displayed in the LMS. However, the LMS currently retrieves all program data from the soon-to-be-retired programs service. Consuming program data exclusively from the catalog service is out of the question right now; it's too complex to confidently pull off in a week. This is a functional middle ground introduced by ECOM-5460. Cleaning up this debt is tracked by ECOM-4418.
