We heard about a bug where learners granted extensions would still
lose access to content if it was marked as "hidden after due date".
This was caused by the HiddenContentTransformer using the due date
from collection time (publish time) rather than the user date returned
from the edx-when DateOverrideTransformer.
A small subtletly of this PR is that Transformers with the
FilteringTransformerMixin are executed before those without it so
part of the fix was to make the HiddenContentTransformer not use the
FilteringTransformerMixin to ensure the DateOverrideTransformer had
run first.
Part 3/3 - Removing old collect code with merged due date
We heard about a bug where learners granted extensions would still
lose access to content if it was marked as "hidden after due date".
This was caused by the HiddenContentTransformer using the due date
from collection time (publish time) rather than the user date returned
from the edx-when DateOverrideTransformer.
A small subtletly of these PRs is that Transformers with the
FilteringTransformerMixin are executed before those without it so
part of the fix was to make the HiddenContentTransformer not use the
FilteringTransformerMixin to ensure the DateOverrideTransformer had
run first.
Part 2/3 - Updating transform method + updating Read version
We heard about a bug where learners granted extensions would still
lose access to content if it was marked as "hidden after due date".
This was caused by the HiddenContentTransformer using the due date
from collection time (publish time) rather than the user date returned
from the edx-when DateOverrideTransformer.
A small subtletly of these PRs is that Transformers with the
FilteringTransformerMixin are executed before those without it so
part of the fix was to make the HiddenContentTransformer not use the
FilteringTransformerMixin to ensure the DateOverrideTransformer had
run first.
Part 1/3
django-not-configured is an error raised by pylint (with
the pylint-django plugin) when it's not correctly configured.
We should not be applying lint amnesty for such a violation.
* Generate common/djangoapps import shims for LMS
* Generate common/djangoapps import shims for Studio
* Stop appending project root to sys.path
* Stop appending common/djangoapps to sys.path
* Import from common.djangoapps.course_action_state instead of course_action_state
* Import from common.djangoapps.course_modes instead of course_modes
* Import from common.djangoapps.database_fixups instead of database_fixups
* Import from common.djangoapps.edxmako instead of edxmako
* Import from common.djangoapps.entitlements instead of entitlements
* Import from common.djangoapps.pipline_mako instead of pipeline_mako
* Import from common.djangoapps.static_replace instead of static_replace
* Import from common.djangoapps.student instead of student
* Import from common.djangoapps.terrain instead of terrain
* Import from common.djangoapps.third_party_auth instead of third_party_auth
* Import from common.djangoapps.track instead of track
* Import from common.djangoapps.util instead of util
* Import from common.djangoapps.xblock_django instead of xblock_django
* Add empty common/djangoapps/__init__.py to fix pytest collection
* Fix pylint formatting violations
* Exclude import_shims/ directory tree from linting
This message comes from the content library block transformer,
and has been filling up our logs at a rate of 250k instances/hr.
Since we don't need to see this log message in production any more,
we are lowering it to the DEBUG level.
The Randomized Content Block XBlock only randomizes the selection of
the children blocks and has unpredictable randomization of
the order of the selected child blocks due to the usage of sets, which
are unordered, for storing the selected blocks. This becomes apparent
when all the available child blocks in a library are chosen for a
Randomized Content Block, to randomize just the order of the child
blocks and not just the selection of the blocks. The order of the
selected blocks ends up being similar for multiple learners.
This change modifies the XBlock to store the selected child blocks in
a list, instead of a set, after randomly shuffling them.
A new block structure transformer, ContentLibraryOrderTransformer has
been added to transform the order of the selected children XBlocks to
match the order of the selections made in the
ContentLibraryTransformer. This ensures that same correct randomized order
of blocks is also returned by the course blocks API.
The Randomized Content Block XBlock only randomizes the selection of
the children blocks and has unpredictable randomization of
the order of the selected child blocks due to the usage of sets, which
are unordered, for storing the selected blocks. This becomes apparent
when all the available child blocks in a library are chosen for a
Randomized Content Block, to randomize just the order of the child
blocks and not just the selection of the blocks. The order of the
selected blocks ends up being similar for multiple learners.
This change modifies the XBlock to store the selected child blocks in
a list, instead of a set, after randomly shuffling them.
We saw an increase in response time with recent changes to the logic
behind get_course_assignments. This effort works to better access
the information we need in order to improve performance.
Namely, this is done by using the course_blocks_api
The Randomized Content Block XBlock only randomizes the selection of
the children blocks and has unpredictable randomization of
the order of the selected child blocks due to the usage of sets, which
are unordered, for storing the selected blocks. This becomes apparent
when all the available child blocks in a library are chosen for a
Randomized Content Block, to randomize just the order of the child
blocks and not just the selection of the blocks. The order of the
selected blocks ends up being similar for multiple learners.
This change modifies the XBlock to store the selected child blocks in
a list, instead of a set, after randomly shuffling them.
The Randomized Content Block XBlock only randomizes the selection of
the children blocks and has unpredictable randomization of
the order of the selected child blocks due to the usage of sets, which
are unordered, for storing the selected blocks. This becomes apparent
when all the available child blocks in a library are chosen for a
Randomized Content Block, to randomize just the order of the child
blocks and not just the selection of the blocks. The order of the
selected blocks ends up being similar for multiple learners.
This change modifies the XBlock to store the selected child blocks in
a list, instead of a set, after randomly shuffling them.
This PR is based on #19284 and is part of the
series of work related to the proposal #18134.
This PR avoids the assignment of
anonymous/unenrolled users to any cohort when
course is public. Anonymous or unenrolled users
will only see content that does not have a
content group assigned.
The "View Course" link to the course outline
is shown on the course about page for a course
marked public/public outline.
It also makes course handouts available for
public courses (not for public_outline).
This PR also hides the different warnings and
messages asking the user to sign-in and enroll
in the course, when the course is marked public.
It modifies the default public_view text to
include the component display_name when
unenrolled access is not available.
All code in this PR should be removed after REVE-52 is merged and mobile
traffic from older app versions falls to < 5% of the mobile traffic
to the course_blocks api
