django-not-configured is an error raised by pylint (with
the pylint-django plugin) when it's not correctly configured.
We should not be applying lint amnesty for such a violation.
https://github.com/edx/edx-platform/pull/26530 updated the tests to use pytest
assertions instead of unittest assertionss. However, some tests depended on custom
equality functions being set up in the test classes. These tests have been updated
to explicitly do the needed comparisons.
* import task decorator from celery APP instance instead of celery package in CMS
* replaced task decorator with shared_task in cms and common
* Fixed import of shared_task
* Fixed import
These changes were initially made to make it easier to do SECRET_KEY rotations. Along the way, we found it made sense to refractor the code as well.
Changes made:
- changed get_to_create to create because now the code should only get to this block when a write is necessary
- added a lookup for anonymous_user_id. This is to return an existing anonymous_user_id rather than calculating. This will mitigate the results of SECRET_KEY rotation.
- Added monitoring to help us make better decisions: should we not sue SECRET_KEY, performance considerations...
- put old function behind toggle in case something goes wrong in production with new code
- refractoring function structure for better understanding
On a platform that is configured to upload video transcripts to S3
(`DEFAULT_FILE_STORAGE = "storages.backends.s3boto3.S3Boto3Storage"`),
uploads from the studio fail with a TypeError: "Unicode-objects must be
encoded before hashing"
A full stacktrace of the issue can be found here:
https://sentry.overhang.io/share/issue/2249b6f67d794c7e986cc288758f4ebe/
This error is triggered by md5 hashing in the botocore library, which
itself is used by the S3Boto3Storage storage class. This error does not
occur with filesystem-based uploads because it does not perform checksum
verification. The reason why this error would not occur on edx.org is
unknown. Similar issues were already fixed from edxval.
To address this issue, we encode the transcript file content prior to
sending it to s3.
There is certain gating logic around pre-reqs, timed exams, etc.
that happen at the SequenceModule level, and should be respected
when rendering descendant XBlocks (like individual problems) that
are in that Sequence. Rather than do a risky refactoring, I'm
keeping that logic where it is and having the render_xblock view
climb up through the ancestor list to call the SequenceModule for
that gating information.
We do _not_ check all descendants (so cousin leaf nodes in the
sequence) for cotent-type-based restrictions because sequences can
become very large (esp. when content libraries are used), and there
is a performance overhead.
If the enclosing sequence is gated in some way, we redirect to the
render_xblock view for that sequence, where hopefully some useful
messaging will be available. This is a stopgap. That redirect
should never happen because we should never be calling the leaf
XBlock for a sequence that is restricted in the MFE. But if somehow
we get there anyway, either by bug or by intrepid user fiddling,
it's better to redirect somewhere that an error _might_ be surfaced
rather than just failing.
This will actually be a little overzealous and lock things down
that should be made visible later. If there's a timed exam and the
exam is completed, it should be the case that content is visible
(just read-only). This commit will block the content before the exam
starts (this is right), open the content while the exam is live
(this is right), but make the content unavailable after the exam
period has finished (this is wrong).
But I am going to go forward with this even knowing it's wrong
because:
1. The render_xblock endpoint should never currently be used in
timed exams in an intentional way. Neither the mobile experience
nor the courseware MFE support it.
2. This fix will address security concerns for creative access
patterns, even if it goes too far.
3. We're going to need to do a lot of work to address both pluggable
access permissions handling and special exams in the courseware
MFE, and a better implementation can be done then.
4. I've had multiple failed attempts to get this to work without
breaking things on and off over the course of weeks, and this
is a relatively low risk way of doing it that doesn't involve
a major refactoring (though the bill for that will come due
when we bring timed exams to the MFE).
Blocks that were hidden by access checks would not be used when
calculating past due status for a unit. This adds in a check to
still look at those blocks, but will maintain not rendering them
when being accessed via the MFE
