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.
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>
- 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
