- update ADR to provide more alternatives for updating
the default value of a flag.
- add a `flag_` prefix to the flag metrics
- add module-level note about flag metrics
- add NewRelic query example and warning
- fix typo in toggle annotation
ARCHBOM-1302
The argument flag_undefined_default is soon to be retired
once ARCHBOM-132 is closed. The following will be used to
help ensure the rollout is complete.
- Add a temporary metric if flag_undefined_default is used.
- Add deprecation warning for flag_undefined_default.
- Add minor fix for waffle flag metric when no request found.
ARCHBOM-132
The previous version of this code used the Django Setting
ENABLE_WAFFLE_FLAG_METRIC to determine whether to add a single
metric with a dict of details about all flags. Due to
NewRelic's 256 character limit on the metric value, this was
getting truncated.
This new version instead uses the Django Setting
WAFFLE_FLAG_CUSTOM_METRICS, a list of waffle flag names to
instrument.
The name of each custom metric will match the name of the flag.
The value of the custom metric could be False, True, or Both.
The value Both would mean that the flag had both a True and False
value at different times during the transaction. This is most
likely due to having a check_before_waffle_callback, as is the
case with CourseWaffleFlag.
ARCHBOM-132
If setting ENABLE_WAFFLE_FLAG_METRIC is True, a custom
metric will be added with the values of all WaffleFlag
and CourseWaffleFlags seen during the transaction.
Metric flag values could be False, True, or Both.
The value Both would mean that the flag had both
a True and False value at different times through
the transaction. This is most likely due to having a
check_before_waffle_callback, as is the case with
CourseWaffleFlag.
Example metric value:
"{'another.course.flag': 'False', 'some.flag': 'False', 'some.course.flag': 'Both'}"
Warning: NewRelic does not recommend large custom
metric values due to the potential performance
impact on the agent, so you may just want to
enable when researching usage of a particular flag.
Metric values longer than 255 are truncated.
TODO: A how_to can be added later if we find this
useful, including helpful querying tips.
ARCHBOM-132
- Add a new CourseEnrollmentCelebration model, which ties a
course enrollment to some booleans about progress celebrations
- Add serialization of the new model to the existing courseware_api
app's existing course info view
- Add new API in courseware_api to update a celebration model
Sometimes a course module will not exist and was causing exceptions
in our weekly highlights mail code. This will hopefully guard against
that a bit better.
Fixing RemovedInDjango30Warnings
**Background:** The `django.shortcuts` method `render_to_response` became deprecated in [Django 1.3](https://docs.djangoproject.com/en/3.0/releases/1.3/), when `render` was introduced.
Per the documentation:
> render() is the same as a call to render_to_response() with a context_instance argument that forces the use of a RequestContext.
Both return an `HttpResponse` object.
**Context:** We changed two statements: An import line and the call to the method, adding explicit parameter names to improve readability.
**Before:**
```
from django.shortcuts import get_object_or_404, render_to_response
...
return render_to_response("teams/teams.html", context)
```
**After**
```
from django.shortcuts import get_object_or_404, render
...
return render(
request=request,
template_name="teams/teams.html",
context=context
)
```
This patch improves on the user locked
out logic by providing a helping message
near locked out. This would help reduce
retries by giving user the option to use
password reset flow to fix the issue.
PROD-1505
- Updating Python Requirements
- Fix cache key generation to use class name and module
This was stringifying the class object directly, resulting in cache keys
like `:1:<class 'xblock_django.models.XBlockConfiguration'>.xblock_django.api.deprecated_xblocks`
which then cause breakage when Django 2.2.13 validates the keys.
Co-authored-by: edX requirements bot <testeng+edx-requirements-bot@edx.org>
Introduces the learning_sequences app, intended to provide metadata for
sequences and course outlines. The short term goal is to provide faster
source of this information for the new Courseware microfrontend
(frontend-app-learning). The medium term goal is to provide an in-proc
API that is useful to other parts of the platform that need fast access
to course outline information customized for a user. The long term
goals are outlined in the README.rst.
This first iteration of the API only lays out the basic structure for
how we'd arrange the pieces, with enough of an implementation to feel
"real" (simple schedules, staff_only content hiding). It's not ready to
be turned on, and is not currently plugged into the publish-flow. The
only way to get data into this new API is via the update_course_outline
management command. The REST endpoint is also currently limited to
global staff only, though it's possible to get the outline for a student
by using the ?username= query parameter.
TNL-7122
