We have found that for many courses on edx.org, the "current version"
of the course that's stored in MongoDB doesn't match what's stored in
MySQL. Although this doesn't directly cause any problems as the
"current version" (course index) is not normally read from MongoDB,
it's not supposed to happen - and it can cause problems if some other
extra-platform components (like a pruner script) read the course
indexes out of MongoDB.
We still aren't sure what can cause MongoDB and MySQL to get out of
sync in the first place; this won't necessarily fix that issue. What
this does fix is a bug that seems to be: once they get out of sync,
they stay out of sync and mongo will stop receiving writes.
The Mongo code in most cases will only write a new record if the
"current" record's last_update matches the last_update value before
the change was made. e.g. last_update is "10am", user makes a change,
Mongo gets updated only if the current row's last_update is still
"10am". Otherwise it's considered a "collision" and silently ignored.
Once Mongo and MySQL somehow become out of sync, they may stay out of
sync because any new writes will have a last_update value read from
MySQL, which is newer than the value in MongoDB, so the MongoDB writes
will all be rejected as "collisions".
This should fix the issue by making mongo writes always match the MySQL
writes, instead of letting the Mongo code "decide on its own" when to
write course index updates or not.
This setting allows loading of Resource Templates from outside the
edx-platform codebase.
Operators will be able to add their own custom resource templates
without needing to fork the codebase.
As part of dissolving our sub-projects in edx-platform, we are moving this package under the xmodule directory.
We have fixed all the occurences of import of this package and also fixed all documents related references.
This might break your platform if you have any reference of `import capa` or `from capa import` in your codebase or in any Xblock.
Ref: https://openedx.atlassian.net/browse/BOM-2582
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>
In a previous PR #28686, the ability to see and enable/disable wiki and progress tabs was removed from studio along with the ability to re-order non-static tabs. The ability to toggle the Wiki tab was moved to the pages and resources section of the course authoring MFE. If that MFE is unavailable this means there is no way to show/hide the Wiki. This reverts some of the old changes if the pages and resources view is disabled.
JIRA: https://openedx.atlassian.net/browse/BOM-2580
This PR aims at refactoring the discussion xblock sub project and moving it within the xmodule directory effectively removing its position as a sub project within edx-platform
- Moving xmodule folder to root as we're dissolving sub-projects of common folder in edx-platform
- More info: https://openedx.atlassian.net/browse/BOM-2579
- -e common/lib/xmodule has been removed from the requirements as xmodule has itself become the part of edx-platform and not being installed through requirements
- The test files common/lib/xmodule/test_files/ have been removed as they are not being used anymore
