As of Python 3.3, the 3rd-party `mock` package has been subsumed into the
standard `unittest.mock` package. Refactoring tests to use the latter will
allow us to drop `mock` as a dependency, which is currently coming in
transitively through requirements/edx/paver.in.
We don't actually drop the `mock` dependency in this PR. That will happen
naturally in:
* https://github.com/openedx/edx-platform/pull/34830
This is an attempt to fix a performance problem on the libraries home page. When you go to studio home and click on the libraries tab, on prod it will be quick for admins but extremely slow for course instructors (> 12 seconds) and leads to timeouts. It grows with the number of libraries that are assigned to the instructor.
The Python code for the request to load libraries for a particular user goes through all existing libraries and then checks all of the user's roles for each library, which results in a complexity of O(l*r), l=libraries, r=roles. This PR improves the complexity to O(l).
The BulkRoleCache and RoleCache classes were using a python set to store all roles for a particular user. A user can have a large number of roles, and lookup speed of iterating through a set is slow (O(n)). Most roles don't have the same course id, however. So if you have the course id of the role you're looking for, we can use a dict of course ids that contain related roles. The number of roles per course id is negligible, so we arrive at a lookup speed of O(1) when looking up a user's roles that belong to a specific course id.
The BulkRoleCache now caches and stores user roles in a data structure like this:
{
user_id_1: {
course_id_1: {role1, role2, role3}, # Set of roles associated with course_id_1
course_id_2: {role4, role5, role6}, # Set of roles associated with course_id_2
[ROLE_CACHE_UNGROUPED_ROLES_KEY]: {role7, role8} # Set of roles not tied to any specific course or library. For example, Global Staff roles.
},
user_id_2: { ... } # Similar structure for another user
}
While this changes the data structure used to store roles under the hood and adds the new property `roles_by_course_id` to the RoleCache,
when initializing the RoleCache will store roles additionally in the previous data structure - as a flat set - in the `_roles` property accessible via `all_roles_set`. This establishes
backwards compatibility.
We are now storing roles twice in the RoleCache (in each of the two data structures), which means this takes twice as much memory, but only in the scope of a request.
* feat: make tagging feature enabled by default
* fix: use the correct flag for tagging enabled
* fix: make compatible with other changes from master
* fix: more compatibility fixes
* fix: show tag counts at all levels of the outline, not just units
* chore: typo
* test: fix counts in test suite now that tagging is on by default
---------
Co-authored-by: Braden MacDonald <braden@opencraft.com>
Co-authored-by: Yusuf Musleh <yusuf@opencraft.com>
* feat: XBlock's children API as DRF
* fix: 500 error appears if user adds a Content Experiment
* fix: wrap into try/except block getting icon for xblock (#2509)
* fix: wrap into try/except block getting icon for xblock
* fix: revision after review
* feat: create DRF endpoint to get course index context
* refactor: update serializers location and added some tests
* refactor: move modulestore usage out of views
* fix: move course index call under bulk_operations
* test: add test to track db and mongo queries
---------
Co-authored-by: ruzniaievdm <ruzniaievdm@gmail.com>
* feat: create DRF endpoint to get course index context
* refactor: update serializers location and added some tests
* refactor: move modulestore usage out of views
---------
Co-authored-by: ruzniaievdm <ruzniaievdm@gmail.com>
* feat: TNL-11173 authoring API offered as v0, not v1
* docs: correct swaggerfile for authoring api
---------
Co-authored-by: Bernard Szabo <bszabo@edx.org>
Co-authored-by: Jesper Hodge <jhodge@outlook.de>
This fixes the routes and swagger details for the experimental CMS API. (The swagger-ui is available under studio.edx.org/cms-api/ui and the schema file at studio.edx.org/cms-api/schema.) Only change that practically affects the routes is that you need to use PUT instead of POST for updates usually, now.
This adds two new urls: `<studio-base>/cms-api/ui` and `<studio-base>/cms-api/schema` with swagger ui and swaggerfile only for the new CMS API using drf-spectacular
The purpose of this is to expose the assets_handler endpoint as a public endpoint as part of the studio content API MVP. This allows a course author to register an oauth application in django admin and then retrieve, create and delete assets with this endpoint. You can only update the "locked" attribute for an asset.
This PR addresses the renaming of the contentstore/xblock_services folder to contentstore/xblock_storage_handlers as a follow-up to PR #32282. The renaming is done to prevent naming conflicts with xblock runtime services and to make the purpose of the files more understandable. The file xblock_service.py has been renamed to view_handlers.py to better reflect its functionality.
Justification and Future Refactoring Outlook:
The xblock_storage_handlers folder contains service methods that implement the business logic for view endpoints located in contentstore/views/block.py. It is renamed to xblock_storage_handlers to reflect its responsibility of handling storage-related operations of xblocks, such as creation, retrieval, and deletion.
The view_handlers.py file includes business methods called by the view endpoints. These methods, such as handle_xblock, delete_orphans, etc., interact with the required modulestore methods, handle any errors, and aggregate and serialize data for the response.
The term 'handler' in the context of 'view_handlers.py' represents methods that facilitate business logic for view endpoints. It is critical to note the distinction between these 'handler methods' and the xblock_handler method. The xblock_handler is a view endpoint itself, residing in contentstore/views/block.py, and is well known in this context. Although its name might suggest otherwise, it is not a handler in the sense of the 'handler methods' we've defined in 'view_handlers.py'. To maintain consistency with existing naming conventions, it remains as xblock_handler.
* feat: add xblock endpoint for updating an xblock
fix: remove debugger
feat: make function call more generic
refactor: just use request.json for request data as before
refactor: extract method
fix: revert wrong method change
fix: refactor correct method
feat: use handle_xblock method so that we can do more than update xblocks
fix: usage_key_string defaults to None
add all CRUD operations
fix usage key parameter
refactor: create /views folder
refactor: move xblock view functions to xblock_services
fix: tests
fix: tests
refactor: move xblock API endpoint to contentstore
* docs: add explanatory comment to new xblock_service
* feat: add feature flag for enabling content editing api
* feat: raise 404 if studio content api is disabled
* tests: test xblock endpoint
* test: make all post tests work
* test: check that xblock_handler receives correct args
* refactor: create util mixin for course factories with staff
* refactor: extract course staff authorization tests
* refactor: extract tests to api view testcase class
* test: add get tests
* test: fix tests
* test: fix tests
* test: fix tests
* test: add all crud tests
* fix: refactor to fix tests
* fix: merge conflict
* fix: merge conflict
* fix: tests after merge
* fix: json request decorator
* fix: lint
* fix: lint
* fix: lint
* fix: lint
* fix: new test files
* fix: lint
* fix: lint and apply PR suggestions
* fix: lint
* fix: lint
* fix: lint
* fix: lint
* fix: lint
* fix: lint
