When a self paced course was published and we were configured to
automatically space out due dates among its sections, we were
accidentally setting due dates on ungraded content. Which limited
access to it.
AA-162
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
