* fix: main page course listing
The course is visible on the main page right after creation when the feature toggle `CREATE_COURSE_WITH_DEFAULT_ENROLLMENT_START_DATE` is on.
So anonymous users can see them and access the course about page
for the courses without valid data (e.g. they will see the default
course overview)
When courses list filtering is processed it checks the `see_exists`
permission for the anonymous user.
Actually, `see_exists` means `can_load` OR `can_enroll`.
`can_load` is False in our case because the course start in the future.
But `can_enroll` returns True because the course's enrollment_start
and enrollment_end dates are blank:
```
enrollment_start = courselike.enrollment_start or datetime.min.replace(tzinfo=UTC)
enrollment_end = courselike.enrollment_end or datetime.max.replace(tzinfo=UTC)
if enrollment_start < now < enrollment_end:
debug("Allow: in enrollment period")
return ACCESS_GRANTED
```
Set the enrollment_start the same as a course start by default
Removed BasicAuthentication as a default from DRF
endpoints that have not overridden the authentication
classes. It appears this is not in use, and was just
implicitly a default because it came from DRF's
defaults.
See DEPR: https://github.com/openedx/edx-platform/issues/33028
Added new authentication classes to be used in
DEFAULT_AUTHENTICATION_CLASSES that include
observability. This will enable us to see more
about the endpoints using the defaults, to help
us make choices about changes in the defaults.
We make the DRF default of Session and Basic
Authentication explicit by setting
DEFAULT_AUTHENTICATION_CLASSES explicitly.
This commit replaces the learning_assistant_launch_url field of the CoursewareInformation view of the courseware API with a learning_assistant_enabled field. learning_assistant_enabled is a boolean that represents whether the Xpert Learning Assistant is enabled for the requesting user, based on the associated CourseWaffleFlag. This change is necessary because we are no longer leveraging the Learning Assistant LTI tool.
* feat: tests for copying units in content_staging app
* chore: convert old tests to pytest style
* feat: make pasting units work (in Studio backend API)
* refactor: make XmlMixin.parse_xml more like standard XBlock behavior
* feat: System defined taxonomies
* style: models.py moved to models/base.py
* feat: New Content System defined models
* style: Lint and migration
* fix: Fix migration error
* chore: Rebase and compile requirements
* refactor: adds ContentTaxonomyMixin for use when creating content system taxonomies
Pulls the ContentTaxonomy-specific logic into a mixin class to bring
the Content-specific logic into other Taxonony subclasses.
* fix: Tests
* test: System defined model validations
* fix: Move language taxonomy creation to openedx-learning
* style: Rename of OrganizationSystemDefinedTaxonomy
* style: nits
* chore: Update openedx-learning dependency
---------
Co-authored-by: Jillian Vogel <jill@opencraft.com>
This takes into account the extra files that are usually required when
copying problems containing JSInputs. Static files such as additional
CSS and JS files needed to interact and style the problem.
* refactor: moves is_content_creator
from cms.djangoapps.contentstore.helpers to common.djangoapps.student.auth
* feat: adds content tagging app
Adds models and APIs to support tagging content objects (e.g. XBlocks,
content libraries) by content authors. Content tags can be thought of as
"name:value" fields, though underneath they are a bit more complicated.
* adds dependency on openedx-learning<=0.1.0
* adds tagging app to LMS and CMS
* adds content tagging models, api, rules, admin, and tests.
* content taxonomies and tags can be maintained per organization by
content creators for that organization.