-
Notifications
You must be signed in to change notification settings - Fork 4.2k
refactor!: use LibraryCollectionLocator and LibraryContainerLocator [FC-0083] #36476
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
refactor!: use LibraryCollectionLocator and LibraryContainerLocator [FC-0083] #36476
Conversation
|
Thanks for the pull request, @pomegranited! This repository is currently maintained by Once you've gone through the following steps feel free to tag them in a comment and let them know that your changes are ready for engineering review. 🔘 Get product approvalIf you haven't already, check this list to see if your contribution needs to go through the product review process.
🔘 Provide contextTo help your reviewers and other members of the community understand the purpose and larger context of your changes, feel free to add as much of the following information to the PR description as you can:
🔘 Get a green buildIf one or more checks are failing, continue working on your changes until this is no longer the case and your build turns green. DetailsWhere can I find more information?If you'd like to get more details on all aspects of the review process for open source pull requests (OSPRs), check out the following resources: When can I expect my changes to be merged?Our goal is to get community contributions seen and reviewed as efficiently as possible. However, the amount of time that it takes to review and merge a PR can vary significantly based on factors such as:
💡 As a result it may take up to several weeks or months to complete a review and merge your PR. |
instead of the LibraryUsageKeyV2 + collection.key in the following functions: * openedx_events LibraryCollectionData * update_library_collection_index_doc * upsert_library_collection_index_doc * searchable_doc_for_collection * searchable_doc_tags_for_collection * upsert_collection_tags_index_docs * update_library_components_collections Also renames uses of collection_usage_key to collection_locator in content_libraries.api: * get_library_collection_usage_key -> library_collection_locator * get_library_collection_from_usage_key -> get_library_collection_from_locator
ba5dfb0 to
95cce4a
Compare
instead of the LibraryUsageKeyV2 + container_key in LibraryContainerData and content.search.handlers.update_library_container_index_doc
rpenido
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 👍
Thank you for your work, @pomegranited!
- I tested this using the CI pipeline
- I read through the code
- I checked for accessibility issues
- Includes documentation
Let me know if you want another check after merging and fixing the conflicts!
|
@pomegranited When creating a Unit, I got this error: |
|
2U Release Notice: This PR has been deployed to the edX staging environment in preparation for a release to production. |
|
2U Release Notice: This PR has been deployed to the edX production environment. |
…FC-0083] (#36476) efactors the content_libraries.api to use LibraryCollectionLocator and LibraryContainerLocator keys, instead of passing separate LibraryUsageKeyV2 keys along with the collection/container locators. Renames misleading uses of collection_usage_key to collection_locator, including in the content_libraries.api and content.search.api method names and parameters. This change impacts Developers, but should not affect end users. This refactoring seems reasonable to do without going through deprecation, given the minimal use of these APIs.
…FC-0083] (openedx#36476) efactors the content_libraries.api to use LibraryCollectionLocator and LibraryContainerLocator keys, instead of passing separate LibraryUsageKeyV2 keys along with the collection/container locators. Renames misleading uses of collection_usage_key to collection_locator, including in the content_libraries.api and content.search.api method names and parameters. This change impacts Developers, but should not affect end users. This refactoring seems reasonable to do without going through deprecation, given the minimal use of these APIs.
…FC-0083] (#36476) efactors the content_libraries.api to use LibraryCollectionLocator and LibraryContainerLocator keys, instead of passing separate LibraryUsageKeyV2 keys along with the collection/container locators. Renames misleading uses of collection_usage_key to collection_locator, including in the content_libraries.api and content.search.api method names and parameters. This change impacts Developers, but should not affect end users. This refactoring seems reasonable to do without going through deprecation, given the minimal use of these APIs.
Description
Refactors the content_libraries.api to use LibraryCollectionLocator and LibraryContainerLocator keys, instead of passing separate LibraryUsageKeyV2 keys along with the collection/container locators.
Renames misleading uses of
collection_usage_keytocollection_locator, including in thecontent_libraries.apiandcontent.search.apimethod names and parameters.This change impacts Developers, but should not affect end users.
This refactoring seems reasonable to do without going through deprecation, given the minimal use of these APIs.
Supporting information
cf openedx/openedx-events#479 (comment)
Blocked by: openedx/openedx-events#487 (merged)
Private-ref: FAL-4120
Testing instructions
Code review + CI should be sufficient for verifying this change.
Manual testing with the Authoring MFE:
Deadline
ASAP -- want to get this in before Teak.