* feat: adds ability to disable posting in discussions indefinitely
* test: fixed ffailing test cases
* test: added new model field in test cases
* refactor: removes unnecessary migrations
* refactor: removed previous migrations and adds new field in discussions api
* refactor: added docstring and changed method name
---------
Co-authored-by: ayesha waris <73840786+ayeshoali@users.noreply.github.com>
Tracks a discussion topics' section and subsection in a new context field so that we have access to that information when the topic's section/subsection/unit has been deleted. This is then used when a topic is deleted to append the section and subsection name to the topic title.
ADR: https://github.com/openedx/edx-platform/pull/29928
This PR changes the default behaviour of the discussions experience by making the previous "unit-level
visibility" the default mechanism for configuring discussions.
Prior to this PR, under the new discussions configuration experience, all units would automatically get
assigned a discussion topic and have discussions enabled for them (other than units in graded or exam
subsections). However, if authors wanted they could enabled a custom visibility mode which would allow
toggling discussions on or off on a per-unit level.
This PR makes this custom visibility mode the standard behaviour (and eventually, only behaviour)
and enables discussion for all units by default. This replicates the behaviour that already existed,
however, now gives authors control over disabling discussions for individual units by default.
It also removes the ability to disable discussions for all units (while still keeping course-wide
discussions) enabled.
The current logic for showing discussion providers makes it hard to switch
from the legacy to the new provider. This commit changes the conditions in
which different providers are shown, and which provider is used as default.
Before this commit, the new provider would be hidden if the legacy provider
was in use and vice-versa. So both would only be shown if neither legacy
nor the new provider were in use (i.e. an LTI provider was in use).
Now, all providers are always displayed to global staff. If the waffle
flag for the new provider is set
(`discussions.enable_new_structure_discussions`), then new provider is
always displayed, and the legacy provider is hidden unless it's currently
in use.
If flag is not set, then the new provider is always hidden unless it is
used by a course.
Finally, the default provider now depends on the flag above. If it is
set globally, then the default provider is the new provider, otherwise
the legacy provider remains the default provider.
* feat: New API for discussion topics
Creates a new API for discussion topics that uses auto-crated discussion topic links for the new discussion provider.
* squash!: refresh migration
* feat: Created API for programs live page zoom lti
* refactor: Merged similar code by inheritance
* refactor: removed duplicates and resolved tight coupling issues
* refactor: Decoupled views
* feat: Adds a new discussion topic configuration mechanism
The new discussion configuration system links discussion topics directly to the course structure. This change adds a new task that sends a discussion update signal if there are any changes to the course. This signal includes all the context needed to update the configuration of the course.
The handler for this new event will create a new entry for each unit that needs a topic in the database. In the future this will be used to see the topics in the course.
* fix: add support for marking a provider as supporting LTI
* fix: review feedback
* 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.
This commit adjusts a few values in our discussions configuration APIs to make them match what the frontend needs, as well as to more accurately reflect the providers available today.
- The `active` provider ID is expressed as None if it doesn’t exist
- The “cs_comments_service” provider has been renamed “legacy” - when we implement the new discussions micro-frontend, we’ll also have a separate provider for that, so they can’t both be “cs_comments_service”. Also, cs_comments_service is such a bad name for anything.
- The hard-coded providers list in get_supported_providers now includes ‘legacy’ and ‘piazza’, our two known providers. This list will be updated as more known providers come online.
- The PROVIDER_FEATURE_MAP has similarly been updated.
Part of this task: TNL-8093
