-
Notifications
You must be signed in to change notification settings - Fork 4.2k
feat: collections support for containers [FC-0083] #36504
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
feat: collections support for containers [FC-0083] #36504
Conversation
|
Thanks for the pull request, @rpenido! 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. 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:
💡 As a result it may take up to several weeks or months to complete a review and merge your PR. |
111684c to
3a7ee98
Compare
3a7ee98 to
b0854a1
Compare
0f63f14 to
88fdc7f
Compare
c372da4 to
8e80240
Compare
fa6bc82 to
ffcc45d
Compare
353d2fd to
8255a8d
Compare
8255a8d to
3ad01b2
Compare
pomegranited
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.
@rpenido This is working great, with the exception of when I "undo delete" (aka restore) a Unit that is part of a Collection.
Have left a bunch of nits, but I love the refactoring you did! Makes things clearer, and you're right, better to do now than later.
Would like to review again once my comments are addressed, but this is looking great.
| else: | ||
| return result |
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.
nit: I'd either remove this else entirely (and let control just fall through), or raise an error about an unexpected OpaqueKey type here?
| else: | |
| return result |
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.
You're right! Fixed here: 20c307b
| library_key: LibraryLocatorV2, | ||
| collection_key: str, |
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.
#36476 started using a single LibraryCollectionLocator key wherever we could, instead of passing the library_key with the collection_key. Can you do the same thing here?
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.
Fixed!
| def to_internal_value(self, value: str) -> OpaqueKey: | ||
| """ | ||
| Returns a UsageKeyV2 or a LibraryContainerLocator from the string value. | ||
| Raises ValidationError if invalid UsageKeyV2 or LibraryContainerLocator. | ||
| """ | ||
| try: | ||
| return UsageKeyV2.from_string(value) | ||
| except InvalidKeyError: | ||
| try: | ||
| return LibraryContainerLocator.from_string(value) | ||
| except InvalidKeyError as err: | ||
| raise ValidationError from err |
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.
If we genuinely don't care what kind of OpaqueKey we deserialize here, this can be simpler:
| def to_internal_value(self, value: str) -> OpaqueKey: | |
| """ | |
| Returns a UsageKeyV2 or a LibraryContainerLocator from the string value. | |
| Raises ValidationError if invalid UsageKeyV2 or LibraryContainerLocator. | |
| """ | |
| try: | |
| return UsageKeyV2.from_string(value) | |
| except InvalidKeyError: | |
| try: | |
| return LibraryContainerLocator.from_string(value) | |
| except InvalidKeyError as err: | |
| raise ValidationError from err | |
| def to_internal_value(self, value: str) -> OpaqueKey: | |
| """ | |
| Returns an OpaqueKey from the string value. | |
| Raises ValidationError if invalid OpaqueKey. | |
| """ | |
| try: | |
| return OpaqueKey.from_string(value) | |
| except InvalidKeyError as err: | |
| raise ValidationError from err |
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.
We pass it through functions as OpaqueKeys, but we have some checks on the keys to check its type:
https://github.com/open-craft/edx-platform/blob/c712133864d3069cc160a6e2f41d04101fc60e30/openedx/core/djangoapps/content_libraries/api/collections.py#L132-L159
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.
That's cool -- then we probably don't need to duplicate these checks in the serializer too, right?
|
|
||
| @shared_task(base=LoggedTask, autoretry_for=(MeilisearchError, ConnectionError)) | ||
| @set_code_owner_attribute | ||
| def update_library_containers_collections(library_key_str: str, collection_key: str) -> None: |
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.
#36476 started using a single LibraryCollectionLocator key wherever we could, instead of passing the library_key with the collection_key. Can you do the same thing here?
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.
Fixed!
c712133 to
881292f
Compare
pomegranited
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.
👍 Working perfectly thank you @rpenido !
- I tested this on my tutor dev stack by adding and removing units to/from collections, deleting a unit that's in a collection, and restoring that unit to ensure the collection link is also restored.
- I read through the code
- I checked for accessibility issues by using my keyboard to navigate
- Includes documentation -- code comments
-
User-facing strings are extracted for translationN/A
navinkarkera
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.
@rpenido Nice work! 👍
- I tested this: (Used frontend to add/remove/update container collections)
- I read through the code
- I checked for accessibility issues
- Includes documentation
|
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. |
Adds support for adding Containers to Collections.
Adds support for adding Containers to Collections.
Description
This PR adds support for adding Containers to Collections.
ToDo:
Supporting information
Testing instructions
Private ref: FAL-4111