In order to gain more information about ongoing questions related to the potentially out-of-sync nature of the SQL and MongoDb tables in Split Modulestore, I have created the management command to list all courses with out-of-sync active_versions and course_index entires.
This should have no direct impact on anyone, nor alter anything.
part of an on-going investigation to figure out 500 errors in studio.
For staff grader setup, we want to know the response type to do better
rendering of the response. This derives from ORA's text_response_editor
setting and is either "text" (default) or "tinymce".
Co-authored-by: nsprenkle <nsprenkle@2u.com>
[MICROBA-1806]
We are aware of product issue where it is possible for a self-paced course-run to get have a `certificate_availability_date` created in the course settings. This can have an adverse effect on the Credentials IDA where a learner's Program Record does not correctly display the course certificates they have earned because of this data. This not only causes confusion for our learners, as it appears that a course certificate a learner can access and share in the LMS is displayed as unearned in the Credential's program record, but this can also cause issues when a learner attempts to share their program record through a credit pathway and the program record would not accurately reflect their program completion.
Unfortunately, the settings that manage the certificate availability date are hidden for self-paced courses in Studio (as they should only be used in instructor-paced courses).
For this reason, we are introducing a management command that will remove a certificate available date for a specified (self-paced) course-run. This will allow us to fix issues for individual learners while we work on a longer-term fix for the larger issue.
* Add new `clean_stale_certificate_available_dates` management command
* Add new `CleanStaleCertificateAvailabilityDates` Configuration Model
* Add tests for the new management command
* (Unrelated cleanup) Fix potential issue with private.py settings in the CMS being overwritten in devstack.py for developers using devstack.
This PR adds MFE API. This is part of the work that is being done to obtain the MFE Runtime Configurations and that has been discussed in the BTR WG.
Discussion: https://discuss.openedx.org/t/how-to-use-microfrontend-in-a-multitenant-instance/6936/14?u=mafermazu
MFE Runtime configuration - eduNEXT: https://docs.google.com/document/d/1-FHIQmyeQZu3311x8eYUNMru4JX7Yb3UlqjmJxvM8do/edit?usp=sharing
feat: add lms setting to set mfe config cache (#262)
Co-authored-by: María Fernanda Magallanes Z <maria.magallanes@edunext.co>
feat: make mfe config api disabled by default (#263)
* feat: make mfe config api disabled by default
* fix: simple is better than complex
test: add mfe config tests (#264)
* test: add mfe config tests
* test: fix it and simplify it
* test: correct pylint issues
fix: correct pep 8 violations
fix: add mfe api unit test in github workflow
fix: correct unit tests
refactor: move mfe api to lms
fix: try mfe api urls without regex
fix: add app_namespace in lms urls
fix: try url without conditional
Revert "fix: try url without conditional"
This reverts commit 694aab546134b4bd9ad2642e24927b42cac24459.
fix: set enable_mfe_config_api feature to true in the tests
test: try to add failed test case
Revert "test: try to add failed test case"
This reverts commit cee6bf656ab1b96492b0b6199ddff32a6d6a65bd.
docs: improve explanation and documentation
fix: ensure the response is a json object
refactor: be consistent with the variable names
fix: allow overriding mfe api config cache timeout in production
fix: handle 404 response in view
refactor: use a guard instead if-else
feat: add the possibility to show mfe specific config
It's safe to remove this because non-staff [1] users cannot access [2]
an `ErrorBlock`. We were able to reproduce this with and without this commit
with the following results:
1. Staff users were seeing the `ErrorBlock`.
2. Non-staff users were getting an empty `<div class="vert-mod"></div>`.
In theory, error blocks should be hidden in the Learning MFE because of this
option [3]. However, when we manually set `hide_access_error_blocks` to
`False`, we kept getting identical results (with and without this commit), so
it looks that the removal `NonStaffErrorBlock` was just omitted at some point.
[1] a4ec4c1b8e/lms/djangoapps/courseware/access.py (L419-L436)
[2] a4ec4c1b8e/lms/djangoapps/courseware/access.py (L150-L151)
[3] 92ca176fde/lms/djangoapps/courseware/views/views.py (L1547-L1551)
There are many `field_data` usages in the platform. Let's categorize them and determine,
which are related to this change and in what way.
- ModuleSystem's argument. This is what we're removing.
- Runtime.field_data. Directly related, as Runtime is ModuleSystem's superclass.
Analysis below this list is centered around this.
- XBlock.field_data. Not related anymore. Runtime.construct_xblock was passing
runtime's field_data to the XBlock's constructor, but that was ~8 years ago.
- DescriptorSystem.field_data. Not related anymore. field_data has been removed
from the constructor long time ago, but you still can see its ancestors
instantiated with field_data=<value> here and there. It's important to note,
that it has been added here in the first place, because field_data was required in Runtime.
- DummySystem, CachingDescriptorSystem, ImportSystem. Not related anymore.
All these classes inherit MakoDescriptorSystem, which inherits DescriptorSystem itself.
So, see the previous item.
- PreviewModuleSystem, TestModuleSystem, LmsModuleSystem — ModuleSystem's ancestors. Directly related.
Basing on that, the only necessary check is to search for ModuleSystem's ancestors using
`field_data` or `_deprecated_per_instance_field_data`. As there are no such cases, it's safe to remove `field_data`.
Co-authored-by: Paulo Viadanna <paulo@opencraft.com>
Co-authored-by: DubeySandeep <dubeysandeep.in@gmail.com>
To exchange jwt with session cookies we need to determine JWT grant type in
AccessTokenExchangeView. JWT only having password grant type will be allowed to exchange session.
Added ADR for mobile migration to JWT authentication.
LEARNER-8886
The username was allowed in the login endpoint alongside the email address
but rate-limiting logic was not updated to rate limit on the new POST
param `email_or_username`.
VAN-1003
