Skip to content

Conversation

@pomegranited
Copy link
Contributor

@pomegranited pomegranited commented Apr 4, 2025

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_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.

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:

  • Ensure you can create, update, and delete library collections, and that these changes show up as expected in the MFE.
  • Repeat ^ for containers (update and delete may not be available yet)

Deadline

ASAP -- want to get this in before Teak.

@openedx-webhooks
Copy link

openedx-webhooks commented Apr 4, 2025

Thanks for the pull request, @pomegranited!

This repository is currently maintained by @openedx/wg-maintenance-edx-platform.

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 approval

If you haven't already, check this list to see if your contribution needs to go through the product review process.

  • If it does, you'll need to submit a product proposal for your contribution, and have it reviewed by the Product Working Group.
    • This process (including the steps you'll need to take) is documented here.
  • If it doesn't, simply proceed with the next step.
🔘 Provide context

To 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:

  • Dependencies

    This PR must be merged before / after / at the same time as ...

  • Blockers

    This PR is waiting for OEP-1234 to be accepted.

  • Timeline information

    This PR must be merged by XX date because ...

  • Partner information

    This is for a course on edx.org.

  • Supporting documentation
  • Relevant Open edX discussion forum threads
🔘 Get a green build

If one or more checks are failing, continue working on your changes until this is no longer the case and your build turns green.

Details
Where 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:

  • The size and impact of the changes that it introduces
  • The need for product review
  • Maintenance status of the parent repository

💡 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
@pomegranited pomegranited force-pushed the jill/container-collection-keys branch from ba5dfb0 to 95cce4a Compare April 4, 2025 03:28
instead of the LibraryUsageKeyV2 + container_key in LibraryContainerData
and content.search.handlers.update_library_container_index_doc
@pomegranited pomegranited marked this pull request as ready for review April 4, 2025 04:29
@pomegranited pomegranited requested a review from rpenido April 4, 2025 04:29
Copy link
Contributor

@rpenido rpenido left a 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!

@mphilbrick211 mphilbrick211 added the FC Relates to an Axim Funded Contribution project label Apr 7, 2025
@ChrisChV
Copy link
Contributor

@pomegranited When creating a Unit, I got this error:

cms-1               | Traceback (most recent call last):
cms-1               |   File "/openedx/venv/lib/python3.11/site-packages/celery/app/trace.py", line 453, in trace_task
cms-1               |     R = retval = fun(*args, **kwargs)
cms-1               |                  ^^^^^^^^^^^^^^^^^^^^
cms-1               |   File "/openedx/venv/lib/python3.11/site-packages/celery/app/autoretry.py", line 38, in run
cms-1               |     return task._orig_run(*args, **kwargs)
cms-1               |            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
cms-1               |   File "/openedx/venv/lib/python3.11/site-packages/edx_django_utils/monitoring/internal/code_owner/utils.py", line 195, in new_function
cms-1               |     return wrapped_function(*args, **kwargs)
cms-1               |            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
cms-1               |   File "/openedx/edx-platform/openedx/core/djangoapps/content/search/tasks.py", line 128, in update_library_container_index_doc
cms-1               |     library_key = container_key.library_key
cms-1               |                   ^^^^^^^^^^^^^^^^^^^^^^^^^
cms-1               | AttributeError: 'str' object has no attribute 'library_key'

@pomegranited
Copy link
Contributor Author

When creating a Unit, I got this error:

Thank you for catching this @ChrisChV ! My last-minute 71afe3f caused this problem, so have fixed with c4329ee. Can you please re-test?

@ChrisChV ChrisChV merged commit 11bab7d into openedx:master Apr 11, 2025
49 checks passed
@ChrisChV ChrisChV deleted the jill/container-collection-keys branch April 11, 2025 15:22
@github-project-automation github-project-automation bot moved this from In Eng Review to Done in Contributions Apr 11, 2025
@edx-pipeline-bot
Copy link
Contributor

2U Release Notice: This PR has been deployed to the edX staging environment in preparation for a release to production.

@edx-pipeline-bot
Copy link
Contributor

2U Release Notice: This PR has been deployed to the edX production environment.

farhan pushed a commit that referenced this pull request Apr 17, 2025
…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.
tonybusa pushed a commit to tonybusa/edx-platform that referenced this pull request Apr 23, 2025
…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.
UsamaSadiq pushed a commit that referenced this pull request May 14, 2025
…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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

FC Relates to an Axim Funded Contribution project open-source-contribution PR author is not from Axim or 2U

Projects

Archived in project

Development

Successfully merging this pull request may close these issues.

6 participants