The render_xblock view, which powers the Learning
MFE (among other things) returned a 404 when un-
enrolled course staff users tried to load it while
masquerading as learners. This was because we
checked course access after enabling the
masquerading context, which triggered a redirect-
to-enrollment exception.
The fix is simply to enable the masquerading
context after checking course access.
Content-level behavior and access is still
calculated within the masquerading context,
as intended.
TNL-7989
Centralize the logic for choosing between
MFE and Legacy-frontend courseware within
three new functions:
* courseware_mfe_is_active
* courseware_mfe_is_visible
* courseware_legacy_is_visible
This allows us to create another new function:
* get_courseware_url
which can be called anywhere in LMS/Studio
to get the canonical URL to courseware
content (whether it be MFE or Legacy).
In future commits we we begin using
get_courseware_url throughout the platform.
TNL-7796
In preparation for switching LMS/Studio over
from serving legacy courseware URLs in certain
places (for example, resume_course_url) to serving
learning micro-frontend URLs.
TNL-7796
* 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
EDUCATOR-4554
This fixes a bug where extended due dates were visible in the outline but not reflected on the courseware pages, resulting in problems not being submittable past the due date.
In order for edx-when to work on courseware pages, it has to be more careful about field inheritance, which version 0.2 achieves.
The verified seat upgrade deadline for self-paced course runs is now
dependent on when the learner was first able to access the content--the
latest of enrollment date and course run start date.
There are a number of Django Signals that are on the modulestore's
SignalHandler class, such as SignalHandler.course_published. These
signals can trigger very expensive processes to occur, such as course
overview or block structures generation. Most of the time, the test
author doesn't care about these side-effects.
This commit does a few things:
* Converts the signals on SignalHandler to be instances of a new
SwitchedSignal class, that allows signal sending to be disabled.
* Creates a SignalIsolationMixin helper similar in spirit to the
CacheIsolationMixin, and adds it to the ModuleStoreIsolationMixin
(and thus to ModuleStoreTestCase and SharedModuleStoreTestCase).
* Converts our various tests to use this new mechanism. In some cases,
this means adjusting query counts downwards because they no longer
have to account for publishing listener actions.
Modulestore generated signals are now muted by default during test runs.
Calls to send() them will result in no-ops. You can choose to enable
specific signals for a given subclass of ModuleStoreTestCase or
SharedModuleStoreTestCase by specifying an ENABLED_SIGNALS class
attribute, like the following example:
from xmodule.modulestore.tests.django_utils import ModuleStoreTestCase
class MyPublishTestCase(ModuleStoreTestCase):
ENABLED_SIGNALS = ['course_published', 'pre_publish']
You should take great care when disabling signals outside of a
ModuleStoreTestCase or SharedModuleStoreTestCase, since they can leak
out into other tests. Be sure to always clean up, and never disable
signals outside of testing. Because signals are essentially process
globals, it can have a lot of unpleasant side-effects if we start
mucking around with them during live requests.
Overall, this change has cut the total test execution time for
edx-platform by a bit over a third, though we still spend a lot in
pre-test setup during our test builds.
[PERF-413]
* Automatically create user partitions on course publish for each ICRV checkpoint.
* Disable partitions for ICRV checkpoints that have been deleted.
* Skip partitions that have been disabled when checking access.
* Add verification access control UI to visibility settings.
* Add verification access control UI to sequential and vertical settings.
* Add partition scheme for verification partition groups.
* Cache information used by verification partition scheme and invalidate the cache on update.
* Add location parameter to UserPartition so the partition scheme can find the associated checkpoint.
* Refactor GroupConfiguration to allow multiple user partitions.
* Add special messaging to ICRV for students in the honor track.
Authors: Zubair Arbi, Awais Qureshi, Aamir Khan, Will Daly
This is an initial authentication implementation that allows LTI users to
log in transparently to edX. The behavior is driven by pilot users at
Harvard; this was the most requested feature.
The patch creates a new database model that maps users' LTI identifiers
to newly-created edX accounts. If an LTI launch comes in with a user_id
field that is not in the database, a new edX account is created with a
random user name and password. This account is then stored in the
database, so that it is permanently associated with the LTI user ID.
This patch takes a simplistic approach to session management. If a user
is logged in with a different account when they perform an LTI launch,
they will be logged out and then re-logged in using their LTI account.
In order to keep the patch simple, I have split out some refactoring
that needs to be done into a separate branch that I'll post once this
has been merged. Since we no longer redirect to the login page, we don't
need to maintain two separate LTI endpoints (one for the LTI launch and
one for authenticated users), or deal with the session management that
requires. There are also multiple fetches of the LtiConsumer object
(one in the view, one in the signature validation) that the later
patch will consolidate into one.
This branch fixes the previous conflicts with the test refactoring
carried out in PR 8240.
Change https://github.com/edx/edx-platform/pull/8240 refactored the LTI
provider template rendering code and introduced an issue where a user was
required to be enrolled in a course before that course's content could be
accessed over LTI. According to the LTI design spec:
https://docs.google.com/document/d/185hdPvIxcKtiDOLjb4sTGovA_WYXWz5Cd79gCzQwBms
we delegate access control over LTI content to the LTI consumer, rather
than requiring that users enroll in edX courses explicitly (and that admins
keep edX and LTI provider enrollemnts consistent when students add or drop
courses).
This change fixes the immediate issue, which is disrupting the LTI Provider
pilot currently running at Harvard.
