Code in ./common/lib/xmodule/xmodule should
be imported as `from xmodule`, since `xmodule`
is a locally-installed package.
This is weird, but as long as it is the case,
we should be consistent.
(In BOM-2584, I propose moving the files to
./xmodule, which would quell this confusion.)
Even if a learner could technically continue to attempt a problem,
if they didn't have any missed deadlines in the course, we would
never display the ability to shift dates. This corrects that to
not require a missed deadline. The banner on the unit is still gated
by needing a missed deadline.
For self-paced courses, we have decided to switch to showing the end
date as long as it is within 365 days rather than the expected
duration of the course.
Also removes the remove_course_goal method as it is no longer
used anywhere and removes the functionality of deleting course goals
if a user unenrolls. Adds in fields for eventing to make them more
useful.
We discovered a subsection that contained a unit without any content
inside, but because of our logic requiring children, it would never be
marked complete (meaning the subsection, section, and course could thus
never be marked complete). This fixes that by removing the children
check from setting completion, but first gating that code path on the
xblock being an aggregator (to prevent leaves from marking as true
simply because there are no children).
Test fixes include adding a test for the empty aggregator case as
well as some changes to not have an entire course marked complete
because they are all empty aggregators.
In DE-1822, we believed we needed to switch to start_date and end_date.
It was determined this was not the case, so this updates the comment
to ensure future users use the correct fields (start and end) and
updates any pieces of code that may have used start_date or end_date.
This djangoapp was designed for talking to sailthru, in a fairly
edx.org-specific way. Nowadays, edx.org doesn't need this code and
if other installations do, it's better off as a more distinct
plugin anyway, rather than direct support in the platform.
I've moved the one signal that was still useful (calling
segment.identify() whenever user fields change) into user_authn.
And I've left the EmailMarketingConfiguration model alone for now,
but will remove that shortly. Nothing uses it as of this commit.
AA-607
DEPR-139
Previously, ProblemBlock's implementation was split between
CapaMixin/CapaFields (in capa_base.py) and ProblemBlock
(in capa_module.py), the former being the base classes of the
latter. The split existed for a historical reason:
as a former XModule, ProblemBlock was once split
between CapaDescriptor (author-facing) and CapaModule
(learner-facing). Since ProblemBlock has been converted
to being a pure XBlock, the division between the base
classes and the block class are no longer necessary
nor semantically helpful.
docs: Flesh out ProblemBlock's docstring a bit.
This helper is used by the LMS, CMS, _and_ `openedx.core`,
so let's move it to `openedx.core` to reduce import complexity.
The following files no longer import from LMS:
- cms/djangoapps/contentstore/management/commands/edit_course_tabs.py
- lms/djangoapps/ccx/migrations/0006_set_display_name_as_override.py
- openedx/core/djangoapps/ccxcon/api.py
- openedx/core/djangoapps/verified_track_content/models.py
- openedx/features/course_experience/plugins.py
Note: The LTI XBlock has a dependency on this import path (!?);
a fix can be found here [1].
- [1] https://github.com/edx/xblock-lti-consumer/pull/154
We have been bucketing all users into the relative dates experiment
since May 18, 2020. We no longer need to keep this as an
ExperimentWaffleFlag and can convert to a CourseWaffleFlag (so it
continues to support exemptions).
The /jump_to/ LMS endpoint is used in a number of places
to direct users to courseware. It currently only redirects to
Legacy courseware URLs, which then conditionally may
redirect to the Learning MFE.
Two issues with this:
1. Performance Impact: In most cases, going to Legacy first
is just an extra redirect.
2. Confusion for Privileged Users: Neither course nor global
staff are auto-redirected from the Legacy experience to the
MFE. Thus, these priviliged users confusingly never see the
MFE by default; they must always manually click into it.
This commit makes it so that /jump_to/ directs
users to whatever the default courseware experience is
for them. For staff of courses active in the new experience,
this will impact (at a minimum) the "View Live"
links in Studio, all links on the old and new LMS
course outline, and the "Resume" links on the course
dashboard. Learners should see no difference other than
a performance improvement when following courseware links
from the LMS.
This also adds an optional 'experience=[legacy|new]'
query param to /jump_to/, allowing us to specifically
generate Legacy courseware URLs for the
"View in Legacy Experience" tool.
TNL-7796
