The XBlockPackageStorage used to return offset-naive datetime objects
which were compared to offset-aware objects when we ran static asset
collection:
./manage.py lms collectstatic
Close CRI-191
* Pull business logic of ProgramCourseEnrollmentOverviewView
out of view class and into utils.py.
* Add UserProgramCourseEnrollmentsView, which is a paginated
version of ProgramCourseEnrollmentOverviewView with a
URL that is parameterized on the user (to enable masquerading
in MST-109).
* Add get_certificates_for_user_by_course_keys to certs API
to make enrollments overviews REST API use fewer SQL queries.
* Document new course cards API with edx-api-doc-tools.
In a follow-up ticket, the Programs Learner Portal will switch
to the new paginatd API in order to speed up its page load.
MST-126
Run isort -rc lms/djangoapps/program_enrollments
Run pylint lms/djangoapps/program_enrollment and fix messages.
Stop pylint from complaining about DictFactoryBase instances
Previously code was only showing banner for enterprise
learners. This patch would remove this restriction
and is available to all edX learners provided that
'enable_secondary_email_feature' is switched on.
PROD-1477
These removed tests can be restored once someone works out why they
were causing flakiness elsewhere and fix the problem.
Reverts tests added in:
dca50aacc3
The cache in the previous version of this code was unwittingly being
shared among all threads, and an occasional race condition would result
in the .children field of some XBlocks containing duplicate entries.
I tried to find other ways to keep the existing cache design and let it
be shared among all the threads (which would be more efficient), but I
couldn't find any clean way of doing it (and even then, this code was
not written with the intention of being used in a multi-threaded way).
So to keep the fix simple, I made the block data cache thread-local
instead of process-local. That eliminated the bug.
Technical details:
The big challenge with this code in the first place was due to the
parse_xml API of XBlocks, which instantiates the XBlock instance and
_then_ sets field data on it and returns it, as there is no mechanism
available to distinguish that from the case of instantiating an XBlock
(using previously loaded/cached field data) and then deliberately
changing its field values. In particular, parse_xml sets the 'children'
field just by calling self.children.append(...) but never explicitly
initializes self.children to [] first, so it's necessary for the field
data store to have a mechanism for setting self.children = [] when
parsing begins, but it's hard to know "when parsing begins" in general.
This is made more challenging since the BlockstoreFieldData design ties
field data changes to the XBlock instance itself (using a weakkey), but
it's impossible to get a reference to the XBlock instance before calling
parse_xml, and since the BlockstoreFieldData design uses a pass-through
approach where fields that aren't being actively changed are read from
the cache; since it doesn't know when children is being initialized vs.
being modified, it would sometimes pass-through and start one thread's
changes with the final result from another thread.
Anyhow, the bottom line is that avoiding unintentional multithreading
here solves the problem.
If we want the field data cache to be shared among threads, it might as
well be rewritten to use memcached and shared among all processes too.
That would be a very good performance boost but would take up a lot more
memory in memcached. Also the rewrite may be challenging due to the
aforementioned nuances of the XBlock parse_xml / construct_xblock /
add_node_as_child APIs. Perhaps modifying the runtime to use a
completely separate fielddata implementation for parsing vs. loading a
parsed+cached XBlock would do it.
Created sorting for email field
updated tests
Fixed sorting issue in registration form
Fixed sorting issue in registration form
Fixed sorting issue in registration form
Added missing items in env and updated order logic
Added missing items in env and updated order logic
ARCHBOM-1139: We were seeing about 150 queries to the django_site table
and over 200 to memcached just to load the login page. A lot of these
are via mako template rendering, but there are other sources, and this
will hopefully nip it in the bud.
Added more info to log in SSO request/response flow
Fixed django admin links on model's link fields which are broken due to django 2.2 upgrade.
ENT-2798
Fixed quality violations and unit test
Fix xsscommitlint violation
Fixed pylint violation
Without this PR, there is no [reasonable] way to get the following data
for any XBlocks in the new runtime; now there is :)
* index_dictionary: data about the block content, for search indexing
* student_view_data: data-only equivalent of student_view, for use in
custom UIs/mobile
* children: list of child IDs
* editable_children: list of child IDs in the same bundle (use case:
when showing an OLX editor you want to allow editing the OLX of
children in the same bundle but not linked children)
This adds some simple new python+REST APIs that can be used to create,
read, update, and delete "links" from a content library to other content
libraries.
One can use these links to import content (XBlocks) into a library
without copying the content.
Note that this feature was already fully supported by Blockstore and the
XBlock runtime; it's just that to use it prior to this required one to
use the (lower-level) Blockstore REST API directly to create the links.
Now there is a somewhat higher-level API built in to Studio, using
"content library" abstractions instead of Blockstore primitives.
