Tests were referring to internal implementation
details of edx-django-utils. This comment removes
those references to free the library up to be
refactored.
ARCHBOM-1584
If the library content block is already in the course, then don't
refresh the children when we re-import it. This lets us address
TNL-7507 (Randomized Content Block Settings Lost in Course Import)
while still avoiding AA-310, where the IDs of the children for an
existing library_content block might be altered, losing student
user state.
When importing, we only copy the default values from content
in a library the first time that library_content block is created.
Future imports ignore what's in the library so as not to disrupt
course state. You can still update to the library via the Studio
UI for updating to the latest version of a library for this block.
Instead of going up the stacktrace to find the module names of waffle
flags and switches, we manually pass the module __name__ whenever the
flag is created. This is similar to `logging.getLogger(__name__)`
standard behaviour.
As the waffle classes are used outside of edx-platform, we make the new
module_name argument an optional keyword argument. This will change once
we pull waffle_utils outside of edx-platform.
Note that the module name is normally only required to view the list of
existing waffle flags and switches. The module name should not be
necessary to verify if a flag is enabled. Thus, maybe it would make
sense to create a `add` class methor similar to:
class WaffleFlag:
@classmethod
def add(cls, namespace, flag, module):
instance = cls(namespace, flag)
cls._class_instances.add((instance, module))
The LEPL dependency was triggering a lot of deprecation warnings of the
form:
venv/lib/python3.5/site-packages/lepl/matchers/support.py:497:
DeprecationWarning: inspect.getargspec() is deprecated, use
inspect.signature() instead
argspec = getargspec(func)
It turns out that LEPL was only used by the rfc6266_parser package, which
itself was only used in one place to generate utf8-compliant
Content-Disposition headers.
This issue was noticed here:
https://github.com/SWW13/python-rfc6266-parser/issues/2
Unfortunately it is quite difficult to extract LEPL from the
rfc6266-parser package.
The rfc6266-parser package (https://pypi.org/project/rfc6266-parser/) is
itself a fork of the now-unmaintained rfc6266 package
(https://pypi.org/project/rfc6266/). Thus, it became high time to get
rid of this package. The FileResponse object can appropriately set the
Content-Disposition header, and thus replace the rfc6266 functionality,
since Django 2.0: https://code.djangoproject.com/ticket/16470
In our testing, the FileResponse object correctly set the
`filename*=utf-8''` value, following the RFC. The only difference is
that it does not provide "filename" fallback value, as expressed in the
RFC: https://tools.ietf.org/html/rfc6266#appendix-D
With rfc6266_parser:
>> import rfc6266_parser
>> rfc6266_parser.build_header("my_file_é.csv", filename_compat="video_urls.csv")
b"attachment; filename=video_urls.csv; filename*=utf-8''my_file_%C3%A9.csv"
With FileResponse we have:
>> from django.http import FileResponse
>> import io
>> response = FileResponse(io.StringIO(), as_attachment=True, filename="my_file_é.csv", content_type="text/csv")
>> response.get("Content-Disposition")
"attachment; filename*=utf-8''my_file_%C3%A9.csv"
We consider that this is a sufficiently minor difference, that will
impact very few browsers.
* Enforce limit on number of blocks allowed in library (blockstore)
* Enforce limit on number of blocks allowed in library (modulestore)
* Changes from review feedback
* testing
* updates to drop down
* unit tests. env changes were copied based on other MFEs in LMS
* added exam settings link to other course settings pages
* fixed pylint errors
* updates for requested changes
* updates for requested changes, as well as changes for xss linter
Add a field to VEM config model that will decide the percentage of
courses allowed to go to VEM pipeline. The courses that don't meet the
criteria will go to VEDA.
PROD-1722
* Disable changing special exam type after release date
Do some client-side validation to make sure that exams
that *are* or *ever were* special may not be changed
to a special exam type (other than the current one)
after release date.
MST-258
Co-authored-by: Zach Hancock <zhancock@edx.org>
In a follow-up PR, this entry will be used to validate
on the client-side that a block that *is* or *ever was*
a proctored/practice/onboarding exam cannot be configured
as a different proctored/practice/onboarding exam, as that
has led to problematic exam configuration states between
edX and proctoring providers.
MST-258
I wanted to make a byte-sized contribution but there were no Jira tickets so we decided, thanks to a conversation with @jmbowman through the Open Edx Community #incr (Slack) channel, to collaborate in the elimination of warnings listed in the Warnings Report at https://build.testeng.edx.org/job/edx-platform-python-pipeline-master/warning_5freport_5fall_2ehtml/
This PR contributes to the elimination of deprecation warnings, specifically the one mentioned above and reported in the Warnings Report.
Changed assertNotRegexpMatches to assertNotRegex in the following files:
cms/djangoapps/contentstore/views/tests/test_preview.py
cms/djangoapps/contentstore/views/tests/test_item.py
lms/djangoapps/commerce/tests/test_views.py
lms/djangoapps/dashboard/tests/test_sysadmin.py
This warning occurs due to deprecation in python 3.5: https://docs.python.org/3.5/library/unittest.html#unittest.TestCase.assertNotRegex
add improved re-write for course updates
add improved re-write for course updates
add edge case test for course update re-write
add edge case test for course update re-write
add edge case test for course update re-write
add edge case test for course update re-write
add edge case test for course update re-write
Before Django 2.1, the dict was being stringified as `{'name': 'file.txt'}`
(note the single quotes) and producing a JSON parse error in
https://github.com/edx/edx-platform/blob/9cf2f9f/cms/djangoapps/contentstore/views/assets.py#L541
which was then converted to a 400 error. However, in Django 2.1,
django.test.client starts JSON-encoding request bodies when an appropriate
content-type is set:
https://github.com/django/django/compare/2.0.8..2.1#diff-97160f50594424a40f2621d5a3c581ccR320
This results in the JSON parse succeeding, and the expected error never
occurs; instead, there is a KeyError when the `locked` attribute is
missing from the dict.
For now, removing the test, since it is blocking Django 2 upgrade work,
and we need to get off of (unsupported) Django 1.11 ASAP.
We should probably repair and restore this test, but it is likely that
we'll want to change the code it is testing first, since that code is
insufficiently defensive and handles both multipart form data and JSON
without properly checking which kind it is dealing with, as well as
assuming too much about what keys are present in the JSON.
I've filed ARCHBOM-1090 for this followup work.
Add integration settings to enable upload of videos from from studio.
Settings enable user to connect to s3 bucket using mfa and assume role
functionality.
PROD-1214
