Cached values were leaking across tests, causing difficult to debug errors,
particularly when using Config Models. As part of this work, certain tests
that had query counts that relied on those values being cached needed to
be adjusted up.
Without this change, we'd throw a TransactionManagementError in the case
where we have a race condition and generate multiple CourseOverviewImageSets
for the same CourseOverview concurrently.
- Remove escaping in display_name_with_default
- Move escaped version to deprecated display_name_with_default_escaped
- Does not include any other changes to remove double-escaping
Thanks to agaylard who initiated this work:
https://github.com/edx/edx-platform/pull/10756
TNL-3425
Course teams occasionally upload very large files as their course
image. Before this commit, those images would be used directly in
the student's dashboard, sometimes leading to MBs worth of image
data on that page. With this commit, we now auto-generate small
and large thumbnails of configurable size. The Student Dashboard
and Course About pages will make use of this new functionality
(CourseOverview.image_urls), but the behavior of
CourseOverview.course_image_url will not change.
Note that the thumbnails are still created in the contentstore,
and sit alongside their originals.
What's included:
1. Multiple sizes, currently starting with "raw", "small", and
"large". This falls back to the current behavior automatically in
the case where thumbnails don't exist or this feature has been
disabled in configuration.
2. Django admin based configuration for image sizes and whether
to enable the functionality at all. Note that to regenerate
images, you'd need to wipe the CourseOverviewImageSet model
rows -- it doesn't do that automatically. This is partly because
it's a very rare operation, and partly because I'm not entirely
sure what the longer term invalidation strategy should be in a
world where we might potentially have multiple themes. The
flexible configuration was intended to allow better customization
and theming.
3. The Course About pages also use the new thumbnail functionality,
as an example of "large". This is in addition to the "small"
used on the student dashboard.
Things I'm punting on for now (followup PRs welcome!):
1. Bringing the thumbnails to course discovery. A quick attempt
to do so showed that it wasn't getting properly invalidated
and updated when publishes happen (so the old image still showed
up). It probably has something to do with when we do the
re-indexing because it stores this data in elasticsearch, but
I'm not going to chase it down right now.
2. Center-cropping. While this is a nice-to-have feature, the
behavior in this PR is no worse than what already exists in
master in terms of image distortion (letting the browser handle
it).
3. Automated invalidation of the images when a new config is
created.
Added the following fields to CourseOverview:
announcement
catalog_visibility
course_video_url
effort
short_description
Now requires CourseOverview models for each course in the system:
Introduced a CourseOverviewGeneratedHistory model to keep track of
when the CourseOverview table was seeded. The seeding can be
done preemptively by calling the generate_course_overview management
command. Otherwise, it is lazily computed, when needed.
This will allow v1 code of CourseOverview to delete entries. While
this is not a good thing in general (and future versions will ignore
entries with higher versions than they support), this is necessary
to prevent errors with the existing code in a rollback situation.
Otherwise, old code trying to delete CourseOverview entries will
fail with a foreign key constraint violation.
Previously, CourseOverview would delete data for any version
that didn't match the current one. That could cause problems
during deploys, when multiple versions of CourseOverview
were active. They would overwrite each other, and that could
cause problems if the old one overwrote the new one -- in
our case, the new one created a new table with foreign key
links that the old one was unaware of, and trying to delete
it would have caused an error.
- Course overviews will cache courses upon publish.
- Added management command to warm up cache.
- OAuth2 handler returns courses via course overviews.
enrollments.
The goal for this PR is to have a single mechanism for registering users and
reducing the number of places where special-casing for ccx courses is needed. The
migration at this point is purposefully limited to convert ccx memberships into
student enrollments when moving forward. No backward migration is in place at the
moment. The ccx membership tables are not removed at this time. It is possible to go
backwards and forwards multiple times with no errors or data loss.
What happened:
* First, I merged `0004_default_lowest_passing_grade_to_None.py`, which adds `null=True` to `lowest_passing_grade`.
* Later, Renzo merged `0004_auto__add_field_courseoverview_enrollment_start__add_field_courseoverv.py`, which adds a bunch of enrollment-related fields
* Neither migrations' `models` variables reflects the changes in the other one.
* release currently has just `0004_default...`
* master and rc/2015-07-22 have `0004_auto...` and `0004_default...`, in that order.
What this commit changes:
* Change `0004_auto...` to `0005_add_enrollment_fields.py`
* Update `models` in `0005_...` to have `null=True` for `lowest_passing_grade`
Sets the Enrollment API free of the modulestore by replacing modulestore queries with calls to the CourseOverview model. Course deletion invalidates the corresponding CourseOverview. XCOM-462.
