Previously software secure was using self sign certificates.
Now they are not using it that's why we are enabling ssl
certificate verfication.
PROD-1395
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.
* Adding samesite cookie option in django 2.1 and above
Django 2.1 release note: Added the SESSION_COOKIE_SAMESITE setting to set the SameSite cookie flag on session cookies.
We want to allow staff to see all courses in the LMS.
This changes the behavior from staff being treated like
an AnonymousUser (unless an username query parameter is
provided) to being treated like staff.
I also added in some tests for the other paths in this
function that did not seem to be tested.
We'll upgrade this again along with pytest once pytest-dev/pytest#6925 is resolved.
Also, it looks like a flaky error in test class DB setup outside a transaction was mucking things up for the rest of the test shard. I didn't try to fix the flakiness, but this should at least limit the blast radius to just that test class. We really need to start using setUpTestData() more consistently.
We're seeing slow commits on production for courseware_studentmodule
updates. Based on the slow queries during those times, we think it
might be because multiple worker processes are trying to update the
same rows from within long-running transactions (since courseware
is relatively slow).
The risk with this is that since the whole view execution is no
longer wrapped in a big implicit transaction, it's possible that
XBlock state will update and things that key off of that (e.g.
completion progress information or pre-req milestones) will fail
in a way that will leave the database in an unplanned-for state,
though this is already the case for those actions that trigger
asynchronous tasks like grades recalculation.
The query counts for the index view test were adjusted down
because save points count towards the total and we're no longer
setting them at the top level around the view as a whole.
