Commit Graph

5 Commits

Author SHA1 Message Date
Feanil Patel
9cf2f9f298 Run 2to3 -f future . -w
This will remove imports from __future__ that are no longer needed.

https://docs.python.org/3.5/library/2to3.html#2to3fixer-future
2019-12-30 10:35:30 -05:00
Braden MacDonald
f31dc19887 Support anonymous users in the Blockstore-based XBlock runtime
Implementation details:
* Anonymous users are assigned a unique ID (like 
  `anon42c08f9996194e2a9339`) which gets stored in the django session.
  `block.scope_ids.user_id` and `block.runtime.anonymous_student_id`
  will both return this value.
* User state for anonymous users is stored in the django cache and
  automatically expires as the cache gets pruned. Because user state is
  stored, anonymous users can use interactive blocks like capa problems.
* There is no mechanism for upgrading to a registered account and
  keeping user state since the user state store for anonymous users
  (EphemeralKeyValueStore) is completely different than the one for
  registered users (DjangoKeyValueStore/"CSM"), and has no "list all
  keys" functionality.
* "User State Summary" field values are shared among [recently active]
  anonymous users but are not shared with registered users.
* Anonymous users can only access the `public_view` of XBlocks, not the
  regular `student_view`.
2019-12-19 16:12:24 -08:00
Braden MacDonald
1382bf8720 Save user state for Blockstore XBlocks in CSM, clean up CSM a bit (#21630)
This commit introduces the changes needed for XBlocks in Blockstore to save
their user state into CSM. Before this commit, all student state for Blockstore
blocks was ephemeral (in-process dict store).

Notes:

* The main risk factor of this PR is that it adds non-course keys to the
  course_id field in CSM. If any code (like analytics?) reads course keys
  directly out of CSM and doesn't have graceful handling for key types it
  doesn't recognize, it could cause an issue. With the included changes to
  opaque-keys, calling CourseKey.from_string(...) on these values will raise
  InvalidKeyError since they're not CourseKeys. (But calling
  LearningContextKey.from_string(...) will work for both course and library
  keys.)
* This commit introduces a slight regression for the Studio view of XBlocks in
  Blockstore content libraries: their state is now lost from request to request.
  I have a follow up PR to give them a proper studio-appropriate state store,
  but I want to review it separately so it doesn't hold up this PR and we can
  test this PR on its own.
2019-09-18 10:27:46 -04:00
Braden MacDonald
ec97387d3e Move new Blockstore key types to external opaque-keys library. 2019-09-13 09:56:44 -07:00
Braden MacDonald
d3f6ed09d8 Learning Contexts, New XBlock Runtime, Blockstore API Client + Content Libraries
https://github.com/edx/edx-platform/pull/20645

This introduces:
* A new XBlock runtime that can read and write XBlocks that are persisted using
  Blockstore instead of Modulestore. The new runtime is currently isolated so
  that it can be tested without risk to the current courseware/runtime.
* Content Libraries v2, which store XBlocks in Blockstore not modulestore
* An API Client for Blockstore
* "Learning Context" plugin API. A learning context is a more abstract concept
  than a course; it's a collection of XBlocks that serves some learning purpose.
2019-08-30 10:31:15 -07:00