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
This commit removes several waffle toggles that have been enabled
on edx.org for years. It's time to remove the rollout gating for
these features and enable them by default.
This doesn't directly change any behavior. But it does create new
database objects by default now and allows for enabling other
schedule based features more easily.
Specifically, the following toggles were affected.
schedules.create_schedules_for_course
- Waffle flag removed as always-enabled
- We now always create a schedule when an enrollment is created
schedules.send_updates_for_course
- Waffle flag removed as always-enabled
- Course update emails are sent as long as the ScheduleConfig
allows it.
- This is not a change in default behavior, because ScheduleConfig
is off by default.
dynamic_pacing.studio_course_update
- Waffle switch removed as always-enabled
- Course teams can now always edit course updates directly in Studio
ScheduleConfig.create_schedules
ScheduleConfig.hold_back_ratio
- Model fields for rolling out the schedules feature
- Schedules are now always created
- This commit only removes references to these fields, they still
exist in the database. A future commit will remove them entirely
This commit also adds a new has_highlights field to CourseOverview.
This is used to cache whether a course has highlights, used to
decide which course update email behavior they get. Previously every
enrollment had to dig into the modulestore to determine that.
This feature uses the first_day_of_streak, last_day_of_streak and last_streak_celebration fields to determine whether the user should see a celebration.
AA-304
This release adds a new permission check when rendering the practice proctored exam view. If a learner is not in a paid enrollment track, the learner will no longer be able to use proctoring software in a practice proctored exam. As with other proctored exams, learners not in a paid enrollment track will see the exam content. This uses the 'can_take_proctored_exam' permission.
Mobile apps load HTML (and other) XBlocks individually using the
render_xblock endpoint. This is an attmept to reduce the number
of requests and JS processing needed to do so by detecting when
we have math content in HTMLBlocks and only adding the Mathjax
resources when necessary.
This is controlled by the "courseware.optimized_render_xblock"
CourseWaffleFlag. For maximum safety, we currently only optimize
in this way when directly hitting HTMLBlocks, and not for
ProblemBlock or VerticalBlock.
This was made as part of edX's Hackathon XXV.
Now that we always return an existing value from the DB rather than trusting that ID generation is deterministic and constant over time, we're free to change the generation algorithm.
Our long term goal is to switch to random IDs, but we need to first investigate the uses of save=False. In the meantime, this is a good opportunity to move away from MD5, which has a number of cryptographic weaknesses. None of the known vulnerabilities are considered exploitable in this location, given the limited ability to control the input to the hash, but we should generally be moving away from it everywhere for consistency.
This change should not be breaking even for save=False callers, since those calls are extremely rare (1 in 100,000) and should only occur after a save=True call, at which point they'll use the stored value. Even if this were not true, for a save=False/True pair of calls to result in a mismatch in output, the first of the calls would have to occur around the time of the deploy of this code.
Co-authored-by: Tim McCormack <tmccormack@edx.org>
Co-authored-by: Tim McCormack <tmccormack@edx.org>
These changes were initially made to make it easier to do SECRET_KEY rotations. Along the way, we found it made sense to refractor the code as well.
Changes made:
- changed get_to_create to create because now the code should only get to this block when a write is necessary
- added a lookup for anonymous_user_id. This is to return an existing anonymous_user_id rather than calculating. This will mitigate the results of SECRET_KEY rotation.
- Added monitoring to help us make better decisions: should we not sue SECRET_KEY, performance considerations...
- put old function behind toggle in case something goes wrong in production with new code
- refractoring function structure for better understanding
This PR lays the groundwork for a an LTI tab that can embed any LTI1.1-based
tool as an course tab. It also adds another tab based on this LTI Tab that
offers special support for embedding LTI-based discussion tools in a course
tab. If enabled this will replace the existing discussion tab.
There is certain gating logic around pre-reqs, timed exams, etc.
that happen at the SequenceModule level, and should be respected
when rendering descendant XBlocks (like individual problems) that
are in that Sequence. Rather than do a risky refactoring, I'm
keeping that logic where it is and having the render_xblock view
climb up through the ancestor list to call the SequenceModule for
that gating information.
We do _not_ check all descendants (so cousin leaf nodes in the
sequence) for cotent-type-based restrictions because sequences can
become very large (esp. when content libraries are used), and there
is a performance overhead.
If the enclosing sequence is gated in some way, we redirect to the
render_xblock view for that sequence, where hopefully some useful
messaging will be available. This is a stopgap. That redirect
should never happen because we should never be calling the leaf
XBlock for a sequence that is restricted in the MFE. But if somehow
we get there anyway, either by bug or by intrepid user fiddling,
it's better to redirect somewhere that an error _might_ be surfaced
rather than just failing.
This will actually be a little overzealous and lock things down
that should be made visible later. If there's a timed exam and the
exam is completed, it should be the case that content is visible
(just read-only). This commit will block the content before the exam
starts (this is right), open the content while the exam is live
(this is right), but make the content unavailable after the exam
period has finished (this is wrong).
But I am going to go forward with this even knowing it's wrong
because:
1. The render_xblock endpoint should never currently be used in
timed exams in an intentional way. Neither the mobile experience
nor the courseware MFE support it.
2. This fix will address security concerns for creative access
patterns, even if it goes too far.
3. We're going to need to do a lot of work to address both pluggable
access permissions handling and special exams in the courseware
MFE, and a better implementation can be done then.
4. I've had multiple failed attempts to get this to work without
breaking things on and off over the course of weeks, and this
is a relatively low risk way of doing it that doesn't involve
a major refactoring (though the bill for that will come due
when we bring timed exams to the MFE).
Blocks that were hidden by access checks would not be used when
calculating past due status for a unit. This adds in a check to
still look at those blocks, but will maintain not rendering them
when being accessed via the MFE
The honor enrollment mode is widely used in OpenEdx installations,
and recently it was not allowed for proctoring exam, but very anticipated.
Current PR makes it possible to start the proctoring exam in the honor enrollment
mode in case the provider is configured in that way.
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`.
The change to masquerade in the courseware view allows the proper
viewing of the xblock from the perspective of the masqueraded user.
In this case, it allows a staff user masquerading as a learner to see
their shift dates calls to action inside the MFE (the old view already
had this set up). The second change allows the staff user masquerading
to reset the schedule of the learner being masqueraded via the CTAs
Specifically, send data versions of course_expired_message and
offer_html.
The rendered HTML is still being sent for now, until the learning
MFE is updated to consume the data objects.
The toggle was previously an ExperimentWaffleFlag,
which allows stable A/B testing but increases the toggle's
complexity. Since we do not plan an doing any more A/B
tests as part of the MFE rollout, we can 'downgrade' this
toggle to a CourseWaffleFlag, which still allows us to do
phased rollout and course-run-specific overrides.
