It is already enabled in devstack LMS, stage LMS/Studio,
and prod LMS/Studio.
However, it is currently disabled in edge LMS/Studio,
and as far as I know, sandbox LMS/Studio as well as the
default Open edX LMS/Studio.
We would like to move towards enabling it globally by
default, and enabling it in devstack Studio would be
a first step towards that.
* Moving plugins infrastructure to edx-django-utils
This PR extracts the code that enables plugins in edx-platform and puts it in edx-django-utils. This is done to allow other IDAS to add plugin functionality.
* Enforce limit on number of blocks allowed in library (blockstore)
* Enforce limit on number of blocks allowed in library (modulestore)
* Changes from review feedback
* testing
* updates to drop down
* unit tests. env changes were copied based on other MFEs in LMS
* added exam settings link to other course settings pages
* fixed pylint errors
* updates for requested changes
* updates for requested changes, as well as changes for xss linter
Ratelimited `login_user` endpoint using `django-ratelimit`, also
decreased default value of logistration rate limit to 100 requests
per five minutes per IP.
PROD-1877
in preparation of dropping support for them entirely.
Re: timing: We will _not_ be going live with this on edx.org at launch;
we'll override this setting on our own installs, initially.
We do, however, want to get this merged ASAP, so that it can still be
pulled into Juniper. That will allow us to drop support in time for the
Koa Named Release, while still providing community operators with a full
Named Release cycle to handle deprecation on their installations.
References:
- [0] TNL-7097
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
The "imp" module is deprecated and should be replaced by "importlib". As
a consequence, loading the django settings used to raise deprecation
warnings:
DeprecationWarning: the imp module is deprecated in favour of
importlib; see the module's documentation for alternative uses
It should be noted that python 3.5.1 ships with an older release of
distutils which still relies on the imp module. Thus, users of python
3.5.1 (for instance: edx.org developers) will continue to see the
deprecation warning for some time, despite this patch. We suggest
upgrading to python 3.5.9.
This addresses part of CRI-196.
We shouldn't be explicitly setting this here. It's already set in all of
our override files and not everyone who wants to use production.py wants
to use SES so we shouldn't hardcode it here.
Also move the other settings to above the config loading so that all
config can be overridden by the config file.
Now that we autoload most keys directly from the yaml file into the
settings context. We don't need boilerplate of the form:
KEY = ENV_TOKENS.get('KEY', KEY)
KEY = AUTH_TOKENS.get('KEY', KEY)
which tries to get the value of KEY from the config file but if it's not
there it pulls it from the defaults found in common.py
This should allow us to remove all the boilerplate code in this file
where a name is pulled from the config dict and put into the top level
namespace of the settings module.
We do this first so that any logic that adds more complex or dynamic
keys will still run and is safe.
Now that this is here we can start removing any simple boilerplate.
1. Created a new celery queue with key `SOFTWARE_SECURE_VERIFICATION_ROUTING_KEY`.
2. Added a celery task with retry logic.
3. sorted imports with isort.
4. Changed deprecated `log.warn` => `log.warning`.
Background: I use private.py a lot in my devstack for my private configurations. But issues are raised when I need to change/override a setting that is defined in devstack_docker.py file. Since that file's contents are loaded after private.py, my private.py is useless against the settings in devstack_docker.py.
Description: Now that the devstack is dockerized, I think it makes more sense to import the private.py in the devstack_docker.py files i.e. at the end of configuration files hierarchy.
BROKER_HEARTBEAT appears to interfere with the celery worker
configuration. If we want to disable or change the heartbeat interval,
It must be from these configuration options.
Just setting --without-heartbeat and/or --heartbeat-interval on the
workers does not fully work. Eg. --without-heartbeat disables sending
heartbeats, but BROKER_HEARTBEAT = 60 means that the connection will get
a 60s heartbeat interval negotiated.
