This uses the new names introduced in edx-django-utils
3.8.0 (edx/edx-django-utils#59), which we're already using, as
well as updating a few other locations where we incorrectly refer
to New Relic custom metrics instead of custom attributes.
Includes a couple of unrelated lint fixes in a file I modified.
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.
Since code-annotations==0.7.0, incremental_release, launch_date,
monitored_rollout, graceful_degradation, beta_testing are all considered
as "temporary" use cases.
Instead of going up the stacktrace to find the module names of waffle
flags and switches, we manually pass the module __name__ whenever the
flag is created. This is similar to `logging.getLogger(__name__)`
standard behaviour.
As the waffle classes are used outside of edx-platform, we make the new
module_name argument an optional keyword argument. This will change once
we pull waffle_utils outside of edx-platform.
Note that the module name is normally only required to view the list of
existing waffle flags and switches. The module name should not be
necessary to verify if a flag is enabled. Thus, maybe it would make
sense to create a `add` class methor similar to:
class WaffleFlag:
@classmethod
def add(cls, namespace, flag, module):
instance = cls(namespace, flag)
cls._class_instances.add((instance, module))
This also starts taking priority into account for all tabs, and
not just dynamic tabs via the CourseTabPluginManager (see comments
in the code for more detail)
- Use the same get_course_outline_block_tree call that the current
outline uses
- Show number of problems in subsection display names
- Don't send links if the user is not enrolled or course isn't public
- Send subsection icons to MFE
- Send subsection descriptions to MFE
- Send completion info to MFE
When the extended courseware module history feature is disabled
(ENABLE_CSMH_EXTENDED=false), the coursewarehistoryextended application
cannot be added to INSTALLED_APPS. Otherwise, the
StudentModuleHistoryExtended model is loaded in the project: it contains
signal receivers that automatically save objects to the student history
table. This table does not exist because the CSMH flag is disabled and
there is no student_module_history database.
So the feature flag is disabled and coursewarehistoryextended is not
part of INSTALLED_APPS: this was the default behaviour in Ironwood. To
make sure that this behaviour keeps working, we also need to make sure
that the migrations do not depend on the coursewarehistoryextended app
when the feature flag is disabled.
