The discussions MFE sends resize and navigation events via the postMessage API, we can use these events to resize the iframe and make sure that the iframe loads the correct page on refresh.
Co-authored-by: Hamza Khchine <hamza.Khchine@opencraft.com>
Co-authored-by: Hamza Khchine <hamza.Khchine@opencraft.com>
* fix: make bulk_email send email task handles a retryable exception
According to bulk_email and SMTP doc, when an error code is between
(400-499) it can be retried after sometime, this commit adds a new
type of exception called SMTPSenderRefused, so it can be retried
**if** it's code fails under above constraint.
* test: add test to handle SMTPSenderResfused
Co-authored-by: Justin Hynes <jhynes@edx.org>
* feat: post handler to sync provider_data
this allows us to read provider_data metadata from a remote metadata url. reuses code from the task that currently processes all proiderconfigs in a batch
ENT-5482
* feat: lint fixes
* test: add test for sync_provider_data
* test: add case for update
* fix: lint fix
* fix: lint fix
* feat: use exc_info to report error better
* feat: update log message
Update the README of the CMS's CourseGraph support app:
* Point to the newly-developed CourseGraph plugin for Tutor,
and remove some prose that's now redundant with the Tutor
plugin's README.
* Add a link to the now-public CourseGraph Queries wiki page.
* Capitalize the G in CourseGraph.
* Fix a couple misc. formatting things.
This introduces two admin actions:
* Dump to CourseGraph (respect cache), and
* Dump to CourseGraph (override cache)
which allow admins to select a collection of courses from Django
admin and dump them to the Neo4j instance specified by
settings.COURSEGRAPH_CONNECTION, with or without respecting
the cache (that is: whether the course has already been dumped
since its last publishing).
The `get_course_last_published` function is used by CourseGraph to
determine whether or not a course should be dumped to Neo4j.
If the course hasn't been published since it was last dumped to
Neo4j, then it can be skipped (unless the override_cache option
is enabled).
The function was previously built using the BlockStructure
data model. While this worked fine in Production instances that
enable `block_structure.storage_backing_for_cache`, this
implementation did NOT work in development environments,
which do not use the BlockStrcture model.
Instead, we switch to using CourseOverview.modified to
approximate when a course was last published. This is method
has fewer moving parts and is universally available across
instances.
Previously, CourseGraph needed to be kept up-to-date by
running `./manage.py dump_to_neo4j ...` manually or on a cron timer.
This introduces a CMS new setting: COURSEGRAPH_DUMP_COURSE_ON_PUBLISH.
When enabled, the CMS course_published signal handler will
asynchronously dump each individual course to CourseGraph when it
is published.
This follows a pattern established by other subsystems like
learning_sequences and special exam registration, both of which
fire off asynchronous post-processing tasks from the course-
publish handler.
Introduce a new CMS settings COURSEGRAPH_CONNECTION,
which allows operators to specify default connection paramters
for a Neo4j instance.
This has three purposes:
* The `./manage.py cms dump_to_neo4j` management command will be
much easier for developers and operators to type out because connection
arguments can now be omitted. Note that connection arguments, if
supplied, will override the arguments specified in CMS settings.
* The automatic push-to-coursegraph-on-publish-signal introduced in
subsequent commits can use these connection settings.
* The CourseGraph Django admin actions introduced in subsequent
commits can use these connection settings.
Move most docs out of docstring and into programatically-
displayable argument help text.
Also, the 'Example Usage' was out of date. This commit updates it to:
* use `./manage.py cms ...' instead of `./manage.py lms ...', and
* use `--port` instead of `--https_port`.
This code was originally located at:
./openedx/core/djangoapps/coursegraph
However, code makes more sense within the ./cms tree, because:
* it is responsible for publishing course content to an
external system, with is within the responsibilities of CMS, and
* is uses modulestore, which is discouraged for use in LMS
(see 0011-limit-modulestore-use-in-lms.rst).
So, we move the code to:
./cms/djangoapps/coursegraph
and uninstall coursegraph from LMS.
We do not expect this refactor to have any breaking downstream effects.
viewing in coursegraph for two reasons. First, the existing log message was misleading
as it implied that a course was being submitted to Neo4j even when it was being
skipped due to not changing since last being sent to Neo4j. Second, the new log
message was not distinctive enough for separate searching in Splunk - it will
now be distinctive enough for that search.
* fix: Add course key or program UUID
Added course key or program uuid for Save For Later
segment event
VAN-905
* fix: fixed failing test
* fix: fixed PEP 8 failure
[MICROBA-1508]
- Adds the InstructorTaskSchedule model
- Adds the HistoricalInstructorTaskSchedule model
- Adds utility function used to create a InstructorTaskSchedule instance
- Adds a public `create_course_email` Python API function to the bulk_email app that can be imported and used in external apps
- Adds a new `test_api_helper.py` test file (with tests for the new `schedule_task` function) to the instructor_task app
- Adds a new `test_api.py` test file (with tests for the new `create_course_email` function to the bulk_email app
Instead of trying to use the devstack settings file for building docs,
use the common settings file as the base for all settings. The
devstack settings file builds on top of the production settings file
which are both oriented around reading settings from a yaml file and
getting them loaded in sanely into the dev and production environment.
For documentation, start with the common settings files which should be
sufficient to get a default version of the system up and running.
Note: We still leave the loop that enables all the feature flags as a way
of finding conditionally included API endpoints.
Most settings in the production.py files fall back to their values in
common.py if they aren't set in the yaml config files but some
historically didn't. Update them so that they are more in-line with the
rest of the settings in this file.
