* 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
* Use full LMS imports paths in LMS settings and urls modules
* Use full LMS import paths in Studio settings and urls modules
* Import from lms.djangoapps.badges instead of badges
* Import from lms.djangoapps.branding instead of branding
* Import from lms.djangoapps.bulk_email instead of bulk_email
* Import from lms.djangoapps.bulk_enroll instead of bulk_enroll
* Import from lms.djangoapps.ccx instead of ccx
* Import from lms.djangoapps.course_api instead of course_api
* Import from lms.djangoapps.course_blocks instead of course_blocks
* Import from lms.djangoapps.course_wiki instead of course_wiki
* Import from lms.djangoapps.courseware instead of courseware
* Import from lms.djangoapps.dashboard instead of dashboard
* Import from lms.djangoapps.discussion import discussion
* Import from lms.djangoapps.email_marketing instead of email_marketing
* Import from lms.djangoapps.experiments instead of experiments
* Import from lms.djangoapps.gating instead of gating
* Import from lms.djangoapps.grades instead of grades
* Import from lms.djangoapps.instructor_analytics instead of instructor_analytics
* Import form lms.djangoapps.lms_xblock instead of lms_xblock
* Import from lms.djangoapps.lti_provider instead of lti_provider
* Import from lms.djangoapps.mobile_api instead of mobile_api
* Import from lms.djangoapps.rss_proxy instead of rss_proxy
* Import from lms.djangoapps.static_template_view instead of static_template_view
* Import from lms.djangoapps.survey instead of survey
* Import from lms.djangoapps.verify_student instead of verify_student
* Stop suppressing EdxPlatformDeprecatedImportWarnings
This change is a follow-up to the chages in PR 8347, which removed the
edX login page from the workflow for a new user. Where previously we
redirected a user to the login page, PR 8347 instead creates a new user
transparently and logs them in.
The initial reason for splitting the LTI view between lti_launch and
lti_run was so that there was a target for the GET request that
followed the login page. Since we no longer use the login page, we
no longer need the second view. We also don't need to store the LTI
parameters in the session any more, since they are not persisting
between calls. This simplifies the view logic significantly.
The other change here is to fetch the LtiConsumer object early in
the view, and pass it to the SignatureValidator and scoring system.
When the views were split, this required multiple DB hits for the
same data; we're now only fetching it once.
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.
This change cleans up the work in progress request at https://github.com/edx/edx-platform/pull/8176
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.
The line below was left in during the refactoring shuffle from PR #8205, and causes
an issue in a corner case where an LTI launch provides an instance GUID where there
wasn't one already set for the consumer. This change fixes the bug, and adds a test
to prevent it from recurring.
This change allows the LTI provider to pass grades back to the campus LMS platform using the
LTI outcome service. For full details of the outcome service, see:
http://www.imsglobal.org/LTI/v1p1/ltiIMGv1p1.html
In brief, the LTI 1.1 spec defines an outcome service that can be offered by an LTI consumer.
The consumer determines whether a score should be returned (in Canvas, this means that the LTI
tool is used in an assignment, and the launch was performed by a student). If so, it sends
two additional parameters along with the LTI launch:
lis_outcome_service_url: the endpoint for the outcome service on the consumer;
lis_result_sourcedid: a unique identifier for the row in the gradebook (i.e. the tool/student/assignment combination).
The LTI Provider launch view detects the presence of these optional fields, and creates database
records for the specific Outcome Service and for the graded LTI launch. Later, when a score on
edX changes (identified using the signal mechanism from previous LTI Provider pull requests),
a Celery task is launched to pass the score back to the LTI consumer.
