Commit 7f59688 attempted to solve this using
`CourseOverview.course_exists`, but that check is case-
insensitive. This commit instead does a small refactor
to `lms.djangoapps.courseware.get_course` so that we can
handle a failed course lookup without broadly catching
a `ValueError`.
* 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
Previously, we'd been avoiding PLS due dates for ORA *sections*.
That is, if a section had only ORA content, we'd not set a PLS
due date for anything in that section.
If any content in that section had non-ORA graded content however,
we would set dates on all subsections, including the ORA one.
This resulted in some ORA-only subsections showing up twice on the
dates tab. So this patch simply brings down the ORA-only check
to a *subsection* level, not a section one.
ORA2 (openassessment) problems have multiple dates associated with are
not bound to the `due` date that is modified by Personalized Learner
Schedules. We expose the ORA2 dates separately in the dates page
so that learners aren't surprised by the differing deadlines.
[AA-223]
When considering if an assignment is past due for the dates tab,
only look at the scored and graded units in the subsection (i.e.
ignore reading and video units).
This still leaves the "complete" field alone -- i.e. those
subsections will still be left incomplete generally. But for
assignment-focused tasks, they will instead be considered complete.
- Looks at masquerading config for dates, outline, metadata, and
celebration APIs in course_home_api / courseware_api.
- Consolidates and cleans up places we check whether masquerading
gives us full access to a course.
This takes over some of the logic in the is_enabled property which
previously checked two things: (1) is the date time-sensitive and
(2) is the date even applicable to this course.
Now, is_enabled is only responsible for time-sensitive checks and
the new is_allowed property checks applicability.
In this way, we can more cleanly separate whether a date block
should show up on the dates sidebar (is_enabled and is_allowed)
and the dates tab (is_allowed).
This change will prefer putting assignments before other course
events (such as end date or verification deadline date) in the
case where they share the same date.
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
TNL-7053
The courseware_api view will use check_course_access - which now returns AccessResponse objects, and all other uses of check_course_access will now use check_course_access_with_redirect, which is a drop-in replacement for the original check_course_access implementation.
We also added a few new helpers to access_utils:
- check_public_access is a replacement for allow_public_access, which now returns AccessResponse objects
- check_enrollment checks if the learner is enrolled, and uses check_public_access to account for COURSE_ENABLE_UNENROLLED_ACCESS_FLAG
- check_survey checks whether there is a required survey that the learner must complete prior to accessing the course.
There are two new kinds of AccessError subclasses:
- SurveyRequiredAccessError
- EnrollmentRequiredAccessError
This is an unused-as-of-yet utility function to generate a bunch
of ics files for a user's course schedule. Will be used as part
of the calendar_sync feature package.
AA-37
