Repository navigation
Consolidate duplicate LMS and CMS settings into platform wide settings #37107
Description
Overview
#36941 introduced the openedx/envs/common.py settings module as a place to put settings shared across the LMS and CMS. In that PR, explicitly shared settings (ones that were being imported into cms/envs/common.py from lms/envs/common.py) we're brought up into openedx/envs/common.py.
This task is to build upon that work and now bring up any setting which is declared in both lms/envs/common.py and cms/envs/common.py and which shares the same value. Make sure to bring any documentation along, and merge the documentation together appropriately if it differs between the LMS and CMS. The settings annotations defined in openedx/envs/common.py will appear in the Platform-Wide Settings section of the settings reference.
Testing
Use the same, or a similar approach to #36941, to make sure that the rendered settings between master and the feature branch do not differ in any significant way.
Notes
This task is part of the effort to simplify settings as outlined in ADR 0022 - Django settings simplification.
Activity
kdmccormick commentedon Aug 4, 2025
There will be some shared settings whose values are consistent between LMS and CMS, and it will be obvious how to consolidate those. For settings whose values differ, how do you think you will handle those (or will you skip them for now)?
wgu-taylor-payne commentedon Aug 4, 2025
@kdmccormick I was planning on skipping settings where the values differ for now, but maybe that is something that we could look at doing next.
Depending on the value of the setting it may need to stay in
cms/envs/common.pyorlms/envs/common.py. I think we could find settings, though, where part of the value is common between the two, and then part is custom to the respective application. In such cases, we could raise the common part up toopenedx/envs/common.pyand make it a derived setting, where the part that is custom to application (cms or lms) is referenced in the derived setting, but the value is defined in its respectivecommon.pyfile.kdmccormick commentedon Aug 4, 2025
SGTM
Agreed, I think that will be a good approach for many settings.
(Just thinking out loud: For a setting whose value has no parts at all in common between LMS and CMS, we could put just a value-less type declaration in
openedx/envs/common.py, e.g.PROJECT_ROOT: str. This would allow us to consolidate the setting's documentation into one place without having to put an LMS-specific or CMS-specific value into the platform-wide defaults. The only problem with that is that we could not specify a single.. setting_defaultannotation. But maybe there is a way around this... I'll keep thinking.)kdmccormick commentedon Aug 4, 2025
This approach looks great to me 👍🏻
kdmccormick commentedon Aug 4, 2025
at risk of stating the obvious: if you start this work soon, I'd base it off of Ram's branch, since many of those settings previously nested within FEATURES will match between LMS and CMS.
wgu-taylor-payne commentedon Aug 4, 2025
Good point, I'll do that.