- This will force the use of the new v2 forum's APIs for Threads & Comment.
- Update params for get_user_subscription function. It uses the same structure as we have in the get_user_threads.
* feat: automatically follow post while createing comments/responses
* feat: follow post when a comment or response is created
* test: updated tests
---------
Co-authored-by: Ayesha Waris <ayesha.waris@192.168.10.28>
Co-authored-by: Muhammad Adeel Tajamul <muhammadadeeltajamul@hotmail.com>
There was problem in filter_discussion_xblocks_from_response(). This
function was breaking the list response for the BlocksInCourseView by
returning a dict instead of list.
Currently the LTI provider implementation auto-creates a random user when
logging in, however, the LTI launch can include relevant user details such as
their email, full name and even a username. This change makes the LTI code
use the provided details if the "Use lti pii" setting is set in the Django
admin.
Adds a new Django setting called `LTI_CUSTOM_PARAMS` that allows extending the
list of optional LTI parameters processed by the platform. These parameters can
be used by plugins for deeper platform integration.
Currently, the sidebar relies only on the XBlock's `category` class attribute
(called `type` in the transformers). This behavior is inconsistent with the
legacy subsection navigation, which relies on the `XModuleMixin.get_icon_class`
method. This commit adds the `icon_class` to the fields collected by the
transformers and uses it to determine whether the "problem" or "video" icon
should be displayed for a unit in the sidebar.
It is possible to create a completable XBlock with children.
An example is the Library Content Block with the
`MARK_LIBRARY_CONTENT_BLOCK_COMPLETE_ON_VIEW` feature toggle.
The sidebar should use the same mechanism as the `BlockCompletionTransformer`
and the `edx-completion` library. It means that we should treat:
1. An aggregator XBlock as completed only when all its children are completed.
2. A completable XBlock as completed when it is directly marked as completed
(without checking the completion of its children).
* feat: return response merged from base config, mfe config and mfe overrides
* test: adjust existing tests
* test: add new test methods
* fix: add blank line
* fix: remove homepage_overlay_html
* fix: typo in a comment
* test: change dict merge order to follow the correct hierarchy
* fix: change response keys to uppercase
* fix: add enable_course_discovery
* fix: change COURSES_ARE_BROWSABLE to NON_BROWSABLE_COURSES
* fix: remove show_homepage_promo_video
* fix: use None as default for promo video youtube id
* docs: expand docstrings, rename method/variables
* fix: remove is_cosmetic_price_enabled field
Since the scheme must be included for the CSRF_TRUSTED_ORIGINS setting since
Django 4.0, this changes the values in the mock.yml configuration files to use
the scheme for the values under CSRF_TRUSTED_ORIGINS. We match the values
defined under CSRF_TRUSTED_ORIGINS_WITH_SCHEME key.
lms/envs/production.py pulls from CSRF_TRUSTED_ORIGINS_WITH_SCHEME in the YAML
config to set the CSRF_TRUSTED_ORIGINS setting , but cms/envs/production.py
pulls from CSRF_TRUSTED_ORIGINS in the YAML. So, this change fixes the CMS when
run with mock.yml.
Run tests for both the built-in and extracted WordCloud block.
The tests are mostly compatible with both versions of the block,
except for a few places where the XBlock framework and the
built-in XModule system differ which we've had to handle using
conditionals.
This moves us closer to enabling the extracted WordCloud block
by default and eventually removing the built-in block.
Part of: https://github.com/openedx/edx-platform/issues/34840
We don't need to load the old UI and so don't need all the logic related
to it, just the logic that is expected to occur around other backend
functionality like masquerading.
This has all been replaced by the learning MFE and will be removed from
the platform in subsequent commits.
For masquerade testing, the page no longer renders content and so
shouldn't be a part of this test. The render_xblock url is what is used
by the MFE so we're still testing that the course-wide content is being
loaded correctly for content served by the learning MFE.
This test tests whether or not we can load the legacy courseware page if
we have not met prerequisites. We don't need this anymore because we
are in the process of removing those pages and the default is now to
load the MFE instead.
The underlying checks still happens as a part of the
`_has_access_course` function which calls
`lms/djangoapps/courseware/access.py:_can_view_courseware_with_prerequisites`
We were running some tests using this function but it is not actually
used in the running application anymore so drop those tests and remove
the function in preparation for removing the legacy courseware itself.
In the effort to simplify settings in edx-platform, as discussed in ADR 22 -
Settings Simplification, this PR brings some of the production defaults defined
in `lms/envs/production.py` and `cms/envs/production.py` up to
`openedx/envs/common.py` or `lms/envs/common.py` and `cms/envs/common.py` as
appropriate.
Bringing these defaults up from the `production.py` settings modules caused
changes in the rendered settings of the `test.py` modules, and so I have
settings to the `test.py` modules to bring the rendered settings back in line
with what is has been. I have not deeply looked at which settings are needed
for tests to pass or not, but just the differences between the rendered
settings between `master` and this branch.
ADR 22: https://github.com/openedx/edx-platform/blob/master/docs/decisions/0022-settings-simplification.rst
Fixes https://github.com/openedx/edx-platform/issues/36892.
* feat: add course_url to course team management GET API response
* fix: update docstring in api views
* feat: Implement CMS course URL generation with HTTPS scheme detection
This PR fixes the task path in the Celery beat settings for the
refresh-saml-metadata scheduled task.
We had previously added the fetch_saml_metadata task to the Celery beat
schedule to run periodically (default: every 24 hours). However, due to a typo
in the task path, Celery workers were throwing errors. This fix corrects the
task path so the schedule can run as intended.
