Previously, an error was raised if the comments service returned data
including an unexpected field, which unnecessarily complicated the
release path for new features, since the list of allowed fields would
need to be modified before cs_comments_service could be modified, and
only then could edx-platform take advantage of the new CS feature. We
still log a warning if an unexpected field is returned, so we will
still be able to tell if the CS returns a corrupt response.
JIRA: FOR-180
This captures real-time metrics for all of the comment client actions,
segregated by course_id, as well as other small-cardinality fields.
The goal is to be able to detect changes in forum usage, with the goal
of alerting on potential error conditions.
Also improves handling in cases where account creation did succeed, but
comments service user creation did not.
Depends on commit 88abdd8a0b20bc9816f487b25abdea1953f5661d in https://github.com/edx/cs_comments_service
JIRA: FOR-522
Adds a split_test_module XModule, that can choose one of its children
to display, based on a get_condition_for_user API added to the runtime.
To test, add something like this to an xml course, or make equivalent
tweaks in mongo.
<vertical url_name="split_test_vert">
<split_test url_name="split1" experiment_id="0" condition_id_to_child='{"0": "i4x://MITx/6.00x/html/split_test_cond0", "1": "i4x://MITx/6.00x/html/split_test_cond1"}'>
<html url_name="split_test_cond0">condition 0</html>
<html url_name="split_test_cond1">condition 1</html>
</split_test>
</vertical>
Also needs an experiment configured in the course policy json: e.g.
"user_partitions": [{"id": 0,
"name": "Experiment 0",
"description": "Unicorns?",
"version": 1,
"groups": [{"id": 0,
"name": "group 0",
"version": 1},
{"id": 1,
"name": "group 1",
"version": 1}]}]
(This particular snippet will work inside a course with org MITx
and course name 6.00x)
Co-Author: Sarina Canelake <sarina@edx.org>
Co-Author: Julia Hansbrough <julia@edx.org>
Co-Author: Diana Huang <diana@edx.org>
Co-Author: Calen Pennington <cale@edx.org>
[LMS-2095]
This requires fixing the javascript api implementation, and adding
an implementation of get_block to the ModuleSystem api.
However, the implementation is incomplete, due to mismatches between
the expectations of XModule and XBlock.
Also adds tests using the Acid block to make sure that the javascript
and python apis for children are working correctly.
Make XBlock client-side runtimes proper classes, so that handlerUrl can
be defined in a per-runtime way, and we can have multiple runtimes on a
single page.
[LMS-1630][LMS-1421][LMS-1517]
fixing unit tests
fixing merge error
fixing xqueue submission issue with unicode url (trial 0.1)
fixing fotmats as commented upon
removing yaml file language selection
Unicode changes to support QRF
removed unnecessary pass in modulestore/init.py
fixing merge error
fixing fotmats as commented upon
removing yaml file language selection
fixing pep8 violations
- fixing pylint violations
pylint violation
fixing line spaces and formats
ignore pylint E1101
remove empty line
fixing pylint violations
pep8 violations
bulk mail unicode/decode
fix migration error
fix pep8 just to push again
more unicode/decode
Final changes to comments and error messages.
Updates to depend on the latest version of XBlock, which includes
support for service-to-service (thirdparty) handler urls, which aren't
authenticated with a user (unlike handler requests coming from the
xblock client-side javascript).
Co-author: Ned Batchelder <ned@edx.org>
This change requires cs_comments_service version 31ef160 or later. Now
that the /threads endpoint can filter by commentable_ids, use that
instead of the /search/threads endpoint, which does not sort and
paginate correctly.
Bug: FOR-224
CommentClientError now has sane subclasses that are meaningfully
distinct, and each subclass is handled appropriately. Errors raised by
the requests library are no longer handled by turning them into
CommentClientErrors, since there is no meaningful handling we can do,
and this way we will get more visibility into why errors are occurring.
Also, HTTP status codes from the comments service indicating client
error are correctly passed through to the client.
Logging the duration of each request will allow us to determine
whether there is a significant difference in the latency reported by
the comments service and that observed by the LMS. Each request will
be assigned a unique identifier to allow correlation of the reported
latency on each end.
Previously, authentication was done using a URL parameter, which would
appear in various logs. Now, authentication is done more appropriately
with an HTTP header. Note that this requires cs_comments_service commit
cf39aabdd160176ebf206ca19d3ee030161a0b47 or later.
According to someone from Datadog, this was generating tags like "knowledgeable_
people_who_put_this_course_together._this_is_harvard._you_can_t_tell_us_there_s_
a_shortage_of_editorial_talent." They say that they can handle tens or hundreds
of unique tags but not thousands. Given that we have a unique URL for each
thread, we can't even use that as a tag. Thus, all tags are removed for now
until we can determine whether there is a useful set of tags with small enough
cardinality. In light of this, I did not investigate why the long tag mentioned
above was being generated.
The LMS comment client previously would try to parse the response
as JSON, choke, and return a 500 to the client. Now, the LMS client
displays a message indicating that the forums are down for
maintenance.
