The current logic for showing discussion providers makes it hard to switch
from the legacy to the new provider. This commit changes the conditions in
which different providers are shown, and which provider is used as default.
Before this commit, the new provider would be hidden if the legacy provider
was in use and vice-versa. So both would only be shown if neither legacy
nor the new provider were in use (i.e. an LTI provider was in use).
Now, all providers are always displayed to global staff. If the waffle
flag for the new provider is set
(`discussions.enable_new_structure_discussions`), then new provider is
always displayed, and the legacy provider is hidden unless it's currently
in use.
If flag is not set, then the new provider is always hidden unless it is
used by a course.
Finally, the default provider now depends on the flag above. If it is
set globally, then the default provider is the new provider, otherwise
the legacy provider remains the default provider.
* fix: update learner home api
* refactor: update learner home API pathing
* fix: remove unused logger
* fix: remove unused import
* style: make pylint happy
* style: remove extra space
* style: remove extra space
Co-authored-by: nsprenkle <nsprenkle@2u.com>
Co-authored-by: Nathan Sprenkle <nsprenkle@users.noreply.github.com>
* This changes the API's path. The reasoning is that this is Version 1 of
the mfe_config API, not Version 1 of the LMS's entire API, so the v1
should come after mfe_config.
* Why does this matter? Firstly, consistency. Secondly, it affects our
generated API documentation. If you visited
https://courses.edx.org/api-docs, you could see that the API was
listed under "v1" instead of "mfe_config".
No functional changes here. This just uses the edx_api_doc_tools package
to add some additional documentation to the new API. The documentation
can be read from the code, or viewed by visiting
http://<LMS_ROOT>/api-docs and searching for "mfe_config".
Formerly, the settings were:
* `MFE_CONFIG` for common config.
* `MFE_CONFIG_<APP_ID>` for app-specific overrides,
with each app getting its own Django setting.
This commit changes it to:
* `MFE_CONFIG` for common config (unchanged)
* `MFE_CONFIG_OVERRIDES` for app-specific overrides,
where each app gets a top-level key in the dictionary.
Why the change?
* We want common.py to have a complete list of overridable settings, as
it helps operators reason about configuration and allows us to generate
config documentation using toggle annotations. Dynamically generating
setting names based on arbitrary APP_IDs makes this impossible.
* getattr(...) generally makes code more complicated bug prone. Tools
like pylint and mypy cannot effectively analyze any code that uses
dynamic attribute access.
* fix: Temporary fix for learners' stats API performance issue
* fix: resolved linter errors
* fix: learners stats API response is now null
* fix: changed waffle dates
* fix: resolved unit test issue
* feat: fill out enrollment serializer
* test: add basic integration tests for enrollments
* feat: get info for user account activation
* test: test integrating user account activation
* feat: get course enrollments
* feat: get course email settings
* feat: add ecommerce info
* feat: add resume urls
* refactor: move learner home to separate app
* refactor: remove course limit
Co-authored-by: nsprenkle <nsprenkle@2u.com>
Currently, the loading sign shows indefinitely if the recommendation API response
is 200 with an empty recommended courses list. Fix, it by showing the general
recommendations.
VAN-1034
The bug is explained in https://openedx.atlassian.net/browse/CRI-233. Only is missing add the `VisibilityTransformer` in `get_blocks()` when the user is not enrolled to the course.
On the test, `html_block` is visible only for staff and `vertical_block` is a normal block. The new behaviour hides the `html_block` and show the `vertical_block` to anonymous users
