Adds the publish status field to the libraries v2 meilisearch index in order to support filtering by component publish status: published, modified, never.
Some of our settings depend on the values of other settings. Rather
than explicitly looking up each one in the YAML settings file, we can
simply derive them based on the setting in the YAML file after all the
YAML settings have been loaded.
Part of: https://github.com/openedx/edx-platform/issues/36215
Co-Authored-By: Feanil Patel <feanil@axim.org>
The Python API for declaring derived settings was confusing to the uninitiated
reader, and also prone to spelling mistakes. This replaces the API with one
that is more readable and more concise, and updates the implementation of
`derive_settings` to properly derive settings declared using the new API.
BREAKING CHANGE: The `derived` and `derived_collection_entry` function are
replaced with the `Derived` class. We do not expect those functions to have
been used outside of edx-platform, but if they are, this commit will cause them
to loudly ImportError.
Note that there should be NO change in behavior to the `derive_settings`
function, which we DO know to be used by some external edx-platform plugins.
Part of: https://github.com/openedx/edx-platform/issues/36215
Quoting the README:
> If you are reading this and the 'Maple' Open edX release is out, you
> can safely delete this whole djangoapp. It only exists to hold old
> model migrations and any post-Maple installation will no longer have
> any model in the database for this app.
>
> But for some minor historical context, this djangoapp used to hold
> some integration with sailthru that we no longer needed.
We've released Sumac. This is overdue.
Fixes the styles for the advanced editors (poll, survey, LTI Provider, etc). Updated the code if `xblock_v2/xblock_iframe.html` to use `course-unit-mfe-iframe-bundle.scss`
In the near term, we wish to precisely preserve the existing values of
all Django settings exposed by lms/envs/production.py in order to avoid
breaking legacy Django plugins without a proper announcement.
That includes preserving the behavior of these old, redundant dicts:
* ENV_TOKENS
* AUTH_TOKENS
* ENV_FEATURES
* ENV_CELERY_QUEUES
* ALTERNATE_QUEUE_ENVS
Particularly, it means we need to ensure that updates to Django
settings are reflected in these dicts. The most reliable way to do that
is to change the yaml-loading logic so that these values are aliased
to the corresponding values in the global namespace rather than
deep-copied.
Finally, we remove KEYS_WITH_MERGED_VALUES from the global namespace,
and inline the remaining list. We have modified the list (specifically,
we dropped the no-op MKTG_URL_OVERRIDES). Plugins should not be counting
on the value of the list, so we remove it.
This reintroduces commit 15939232d5,
which was reverted due to a typo.
The typo is fixed in the commit immediately following this one.
Co-Authored-By: Feanil Patel <feanil@axim.org>
The `dump_settings` command currently prints out the raw `repr(...)`s for
defined functions, e.g.:
"WIKI_CAN_ASSIGN": "<function CAN_ASSIGN at 0x74ce5e9b2020>",
In addition to being uninformative, these `at 0x74ce...` hashes change every
run, so they appear in the diff as having "changed" every time. With this
commit, here's what `dump_settings` will print out for a function instead:
"WIKI_CAN_ASSIGN": {
"module": "lms.djangoapps.course_wiki.settings",
"qualname": "CAN_ASSIGN"
},
`notify_credentials` has 2 ways of running.
1. The manual, one-off method which uses `--args_from_database` to specify what should be sent.
2. [The automated method](7316111b35/openedx/core/djangoapps/credentials/management/commands/notify_credentials.py (L157-L159)), which runs on a regular schedule, to catch anything which fell through the cracks.
The automated method does a certain amount of time/date math in order to calculate the entry point of the window based on the current runtime. This is, I assume, why it has some hardcoded logic; it's not at all simple to have a `cron`-run management command running on a regular cadence that can do the same time logic.
```py
if options['auto']:
options['end_date'] = datetime.now().replace(minute=0, second=0, microsecond=0)
options['start_date'] = options['end_date'] - timedelta(hours=4)
```
However, it is not ideal that the actual time window of 4 hours is hardcoded directly into `edx-platform`.
This fix
* creates an overridable `NOTIFY_CREDENTIALS_FREQUENCY` that defaults to 14400 seconds (4 hours).
* pulls that frequency into the quoted code
Using seconds allows maximum flexibility.
FIXES: APER-3383
This command dumps the current Django settings to JSON for
debugging/diagnostics. The output of this command is for *humans*... it
is NOT suitable for consumption by production systems.
In particular, we are introducing this command as part of a series of
refactorings to the Django settings files lms/envs/* and cms/envs/*.
We want to ensure that these refactorings do not introduce any
unexpected breaking changes, so the dump_settings command will both help
us manually verify our refactorings and help operators verify that our
refactorings behave expectedly when using their custom python/yaml
settings files.
Related to: https://github.com/openedx/edx-platform/pull/36131
* fix: catch a possible exception in beta course configuration
when the learner is a beta tester, and the beta test has been set up with a large duration, the courseware djangoapp can return an overflow error on a timedelta call. In those circumstances, this defaults to returning an unmodified date.
FIXES: APER-3848
Adds the concept of "downstream-only" fields to the XBlock upstream sync logic.
Downstream-only fields are customizable fields set only on the downstream XBlock -- we don't keep track of the upstream field value anywhere on the downstream XBlock. Changes made to these fields in the upstream block are ignored, and if the link to the upstream block is severed, the downstream changes are preserved (not reset back to defaults, like the upstream-tracked customizable fields are).
The fields chosen as "downstream-only" are those related to scoring and grading.
The `max_attempts` field was previously a customizable field that tracked the upstream value. However, because it is scoring-related, it has been converted to a "downstream-only" field.
This change impacts course authors' use of library content in their courses.
* feat!: Removing the long-deprecated legacy course_modes chooser
`course_modes/choose.html` (and its corresponding
`_upgrade_button.html`) were specifically only used for the edge case
where an enterprise user found themselves in the non-enterprise learner
dashboard, and attempted to enroll in a course outside of the
enterprise flow. Once upon a time, in a 2U-only workflow, the commerce
system would apply specific discounts for users within the said case.
That's no longer true, and it has never been true outside of this one
company.
Removing this template cleans up a legacy version of a legacy page that
was, realistically, exclusively seen by employees of 2U,
and nobody else.
Removes:
* The corresponding testsfor behavior only seen in the legacy page.
* A waffle flag since all cases route as if the flag is set: `VALUE_PROP_TRACK_SELECTION_FLAG`: `course_modes.use_new_track_selection`
* Some variables set in `CourseModeView` which were only ever rendered in the legacy template (`title_content`, `has_credit_upsell`) have been removed from the class.
* There is a high likelihood that the class is still a target for re-factoring now that the legacy view is gone, but I'm hesitant to touch something which is not covered by previously existing tests, because the logic around what template gets rendered when is complex.
FIXES: APER-3779
FIXES: #36090
