* Generate common/djangoapps import shims for LMS
* Generate common/djangoapps import shims for Studio
* Stop appending project root to sys.path
* Stop appending common/djangoapps to sys.path
* Import from common.djangoapps.course_action_state instead of course_action_state
* Import from common.djangoapps.course_modes instead of course_modes
* Import from common.djangoapps.database_fixups instead of database_fixups
* Import from common.djangoapps.edxmako instead of edxmako
* Import from common.djangoapps.entitlements instead of entitlements
* Import from common.djangoapps.pipline_mako instead of pipeline_mako
* Import from common.djangoapps.static_replace instead of static_replace
* Import from common.djangoapps.student instead of student
* Import from common.djangoapps.terrain instead of terrain
* Import from common.djangoapps.third_party_auth instead of third_party_auth
* Import from common.djangoapps.track instead of track
* Import from common.djangoapps.util instead of util
* Import from common.djangoapps.xblock_django instead of xblock_django
* Add empty common/djangoapps/__init__.py to fix pytest collection
* Fix pylint formatting violations
* Exclude import_shims/ directory tree from linting
OeX_ES-44: Update edx-search elasticsearch.
* removes redundant doc_types from the lms/cms, replaces courseware
index with doc_types to two indices
* code polishing
* Use a new config variable for ES7 deployment. (#2226)
Co-authored-by: Golub-Sergey <1.golub.sergey.1@gmail.com>
Co-authored-by: Diana Huang <diana.k.huang@gmail.com>
When listing courses for which a user has "staff" level access, bypass
calls to has_access() and use a hopefully more performant and simpler
access pattern that uses only a single ORM query and far less processing
per course.
Caution: this short-circuit implementation does not handle org-level
access grants.
- Looks at masquerading config for dates, outline, metadata, and
celebration APIs in course_home_api / courseware_api.
- Consolidates and cleans up places we check whether masquerading
gives us full access to a course.
Adds a course_ids api that can filter by user role, since the courses
api could not perform well enough for this, and returned much more
data than we need.
Additionally, adds a LazyPageNumberPagination to provide more accurate
counts in the pagination response when using LazySequence with the
queryset.
BOM-897
BOM-1228
The api is already not very performant and trying to limit it to only
show courses where you are staff causes the code to iterate over almost
all the courses and times out before it returns any results to the user.
The plan is to build a different api for the thing we need that will
just provide the course IDs for courses where you are staff and sholud
be much faster.
made changes to test with previous version of django-waffle
updated the query count to test
testing with version 0.13
testing with version 0.14
testing with version 0.15
added version 0.14
updated the django-waffle version to use 0.18
updated the django-waffle version to use 0.16
updated the query counts to pass tests
ran make upgrade
updated the django-waffle to support django 2.2
made changes to test with previous version of django-waffle
updated the query count to test
testing with version 0.13
testing with version 0.14
testing with version 0.15
added version 0.14
updated the django-waffle version to use 0.18
updated the django-waffle version to use 0.16
updated the query counts to pass tests
removed the pdb statements
ran make upgrade
This adds middleware that will create custom parameter metrics in
New Relic to track the size of all the cookies being received for
our domain. The custom fields are "cookies_total_size" and a
separate named parameter for every cookie size, e.g.
"cookies.csrftoken.size".
This is intended to help us track cookie growth and better diagnose
issues where users lose their sessions. It is toggled by the
'request_utils.capture_cookie_sizes' Waffle Flag.
Prior to this commit, the course api (/api/courses/v1/courses/)
performed all the work necessary to return all courses available
to the user, and then only actually returned on page's worth of those
courses.
With this change, the api now does the work incrementally, computing
only the data needed to fetch the courses up to and including the page
being returned. This still increases approximately linearly as
the page number accessed being increases, but should be more cache-friendly.
One side effect of this is that the max_page reported by pagination
will be an overestimate (it will include pages that are removed due
to a users access restrictions).
This change also changes the sort-order of courses being returned by the
course_api. By sorting by course-id, rather than course-number, we
can sort in the database, rather than in Python, and defer loading data
from the end of the list until it is requested.
REVMI-90
Prior to this commit, the course api (/api/courses/v1/courses/)
performed all the work necessary to return all courses available
to the user, and then only actually returned on page's worth of those
courses.
With this change, the api now does the work incrementally, computing
only the data needed to fetch the courses up to and including the page
being returned. This still increases approximately linearly as
the page number accessed being increases, but should be more cache-friendly.
One side effect of this is that the max_page reported by pagination
will be an overestimate (it will include pages that are removed due
to a users access restrictions).
This change also changes the sort-order of courses being returned by the
course_api. By sorting by course-id, rather than course-number, we
can sort in the database, rather than in Python, and defer loading data
from the end of the list until it is requested.
REVMI-90
