Calling runtime.handle('progress', ...) was causing a 404 error due to
the runtime handler. It should be okay for xblocks to submit a
completion or progress event; they just shouldn't have it treated
specially.
EDUCATOR-1642
* Submit a completion when receiving a completion event from an XBlock.
* Handle legacy progress events.
* Convert handler to use a dispatch dict instead of an if-else chain.
* Extract masquerade checking from individual handlers.
* Gate submit_completion on waffle switch
* 404 on handler views when trying to submit completion without waffle
switch enabled.
OC-3087
Disallow calling submit_completion when waffle flag is disabled.
Add tests that trying to publish completion errors.
This reverts commit 1224e341de. I've also added
NotImplementedPartitionScheme, which allows deprecated partition types to have
a valid entry point despite being unusable.
TNL-6675
When crawlers like edX-downloader make requests on courseware, they are
often concurrently loading many units in the same sequence. This causes
contention for the rows in courseware_studentmodule that store the
student's state for various XBlocks/XModules, most notably for the
sequence, chapter, and course -- all of which record and update user
position information when loaded.
It would be nice if we could actually remove these writes altogether
and come up with a cleaner way of keeping track of the user's position.
In general, GETs should be side-effect free. However, any such change
would break backwards compatibility, and would require close
coordination with research teams to make sure they weren't negatively
affected.
This commit identifies crawlers by user agent (CrawlersConfig model),
and blocks student state writes if a crawler is detected. FieldDataCache
writes simply become no-ops. It doesn't actually alter the rendering
of the courseware in any way -- the main impact is that the blocks
won't record your most recent position, which is meaningless for
crawlers anyway.
This can also be used as a building block for other policy we want to
define around crawlers. We just have to be mindful that this only works
with "nice" crawlers who are honest in their user agents, and that
significantly more sophisticated (and costly) measures would be
necessary to prevent crawlers that try to be even trivially sneaky.
[PERF-403]
For better user-facing performance, the SCORE_CHANGED signal is now handled by
enqueueing an async task to update the relevant stored grade, rather than
making the request wait until that operation finishes.
TNL-5738
* First take at forcing a subsection's grade to update when a signal is
sent that a problem's score has changed
* Refactor signal handler connection.
* Expand bokchoy tests to cover progress page
* Add some grading unit tests
TNL-5394
TNL-5364
