The announcements editor was never ported to frontend-app-authoring, and
the announcements display was never ported to frontend-app-learner-dashboard.
This announcements feature is rarely used, undocumented, non-a11y-friendly, and
there were no volunteers to port it to the new frontends. It is the last
remaining part of the legacy Studio "Maintenance" dashboard. So, we are
removing it.
BREAKING CHANGE: This removes...
* Studio Maintenance dashboard legacy frontend
* Studio Edit Announcements legacy frontend
* The snippet of legacy learner dashboard which renders announcements
* openedx/features/announcements djangoapp
* The ENABLE_ANNOUNCEMENTS feature flag
Not removed:
* The announcements_announcement table from openedx/features/announcements .
The table is most likely very small, as it is only populated by administrators. Removing
it would be more labor for us and more risk of toil for operators than is worthwhile.
Closes: https://github.com/openedx/edx-platform/issues/36263
The Studio Maintenance app had two features:
* "Force Course Publish", which literally doesn't do anything. All it
does is tell you what version *would* be seen by users *if* the course
were to be published--no publishing actually occurs via this feature.
* "Announcements", which writes to the announcements_announcement
database table, but doesn't actually display anywhere.
Having these pages in the platform is actively misleading and creates a
maintenance burden for edx-platform developers, so we remove them.
Note that this commit does not include a migration for the announcements
Django app. So, announcements_announcement table will not be deleted.
Given the small expected size of any past-authored announcements, we are
not worried about leaving them in the database perpetually.
This is a new XBlock that presents a random subset of its children. As of this commit, the block
can only be added as an Advanced component. For Sumac, we plan to enable it as part of the
Libraries Relaunch Beta, under the name "Problem Bank (Beta)"
The block does not care if its children are from V1 library, V2 library, or the course itself.
It shares the randomization logic with LegacyLibraryContentBlock. It is also fully backwards-compatible with LegacyLibraryContentBlock. So, once V1 libraries are migrated to V2 libraries (after Teak), we eventually
could point the `library_content` entry point at ItemBankBlock.
Part of: https://github.com/openedx/frontend-app-authoring/issues/1385
The V2 libraries project had a few past iterations which were never
launched. This commit cleans up pieces from those which we don't need
for the real Libraries Relaunch MVP in Sumac:
* Remove ENABLE_LIBRARY_AUTHORING_MICROFRONTEND,
LIBRARY_AUTHORING_FRONTEND_URL, and
REDIRECT_TO_LIBRARY_AUTHORING_MICROFRONTEND, all of which are obsolete
now that library authoring has been merged into
https://github.com/openedx/frontend-app-authoring.
More details on the new Content Libraries configuration settings are
here: https://github.com/openedx/frontend-app-authoring/issues/1334
* Remove dangling support for syncing V2 (learning core-backed) library
content using the LibraryContentBlock. This code was all based on an
older understanding of V2 Content Libraries, where the libraries were
smaller and versioned as a whole rather then versioned by-item.
Reference to V2 libraries will be done on a per-block basis using
the upstream/downstream system, described here:
https://github.com/openedx/edx-platform/blob/master/docs/decisions/0020-upstream-downstream.rst
It's important that we remove this support now so that OLX course
authors don't stuble upon it and use it, which would be buggy and
complicate future migrations.
* Remove the "mode" parameter from LibraryContentBlock. The only
supported mode was and is "random". We will not be adding any further
modes. Going forward for V2, we will have an ItemBank block for
randomizing items (regardless of source), which can be synthesized
with upstream referenced as described above. Existing
LibraryContentBlocks will be migrated.
* Finally, some renamings:
* LibraryContentBlock -> LegacyLibraryContentBlock
* LibraryToolsService -> LegacyLibraryToolsService
* LibrarySummary -> LegacyLibrarySummary
Module names and the old OLX tag (library_content) are unchanged.
Closes: https://github.com/openedx/frontend-app-authoring/issues/1115
Implements the connection from the teams feature to the content groups feature. This implementation uses the dynamic partition generator extension point to associate content groups with the users that belong to a Team.
This implementation was heavily inspired by the enrollment tracks dynamic partitions.
Originally, we planned to add support for V2 libraries and for static
(hand-selected) library block reference via new block type: library_sourced.
We have since decided that it would be better to add those capabilities
in-place to the existing library_content block. This will ease V1->V2
library migration and make adoption of the new features easier for current
library users. It will also avoid duplication of logic between two block types,
we we fear would be error-prone. For details, see this ADR:
https://github.com/openedx/edx-platform/pull/33231
So, we are removing the library_sourced block.
This block has existed in edx-platform for a few years now, but was not
enabled by default and never officially supported. It was only usable via the
experimental V2 content library feature. Operators who added library_sourced
blocks to their course will now see them render as `HiddenBlock` instances, i.e.:
> ERROR: "library_sourced" is an unknown component type...
This should not impact other component types in such courses and should not
impact import/export.
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)
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
Unfortunately, some code in edx-platform is imported
relative to sub-projects instead of the repository root.
The only three remaining instances of this are:
* common/lib/xmodule/xmodule (imported as just 'xmodule')
* common/lib/capa/capa (imported as just 'capa')
* openedx/core/lib/xblock_builtin/xblock_discussion
(imported as just 'xblock_discussion')
For more details on the situation, see:
https://openedx.atlassian.net/browse/BOM-2579
(public, but requires Atlassian account creation).
We would like to get to a point where all edx-platform
import paths match their folder paths, relative to the repo
root. For now, though, all common/lib/capa and common/lib/xmodule
code should be imported as just `from capa` and `from xmodule`,
respectively. Importing using the full `common.lib.xmodule.xmodule...`
path will often work, but it instantiates a second instance of all
modules imported this way, which in the past has led to very
difficult-to-diagnose bugs. It also confuses tooling such as
import-linter, which we are trying to add to edx-platform
(see https://openedx.atlassian.net/browse/BOM-2576)
* feat: Adds discussions settings for new discusions experience
This commit adds new discussions settings for the new discussions experience. These are stored in the course so they can be a part of course import/export flow.
These are also added to the discussions configuraiton API to allow MFEs to update the settings.
The discussions API is currently available via LMS, however that means it cannot save changes to the modulestore. This also adds the API to the studio config so it can now also be accessed from studio and be used to save course settings.
* fix: tests
This commit adds new discussions settings for the new discussions experience. These are stored in the course so they can be a part of course import/export flow.
These are also added to the discussions configuraiton API to allow MFEs to update the settings.
The discussions API is currently available via LMS, however that means it cannot save changes to the modulestore. This also adds the API to the studio config so it can now also be accessed from studio and be used to save course settings.
created CustomPagesCourseApp class
feat: created custom pages course app plugin
created CustomPagesCourseApp class
added CUSTOM_PAGES_HELP_URL to lms and cms settings
added entry point to setup.py
feat: added toggle to ENABLE_CUSTOM_PAGES in lms and cms settings
feat: removed the option to enable/disable the availability of custom pages course apps.
* feat: Course Apps API
This adds a new concept called course apps. These are exposed via a new
"openedx.course_app" entrypoint, which helps the LMS and studio discover such
apps and list them in a new rest api for the same.
These course apps will drive the pages and resources view in the course authoring
MFE. This system will track which apps are enabled and which are disabled. It
also allows third-party apps to be listed here by using the plugin entrypoint.
* Apply feedback from review
