Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Basic CRUD REST Endpoints for units in content libraries [FC-0083] #36371

Merged
merged 33 commits into from
Mar 28, 2025
Merged

Basic CRUD REST Endpoints for units in content libraries [FC-0083] #36371

merged 33 commits into from
Mar 28, 2025

Conversation

bradenmacdonald
Copy link
Contributor

@bradenmacdonald bradenmacdonald commented Mar 12, 2025 •
edited by pomegranited
Loading

Description

Implements openedx/frontend-app-authoring#1703

This PR adds python and REST APIs for creating Units in content libraries.

Supporting information

Depends on:

Includes commits from:

Testing instructions

  1. Set up the dependency PRs in your devstack/python environment.
    • Tip: if you add opaque-keys to this list in tutor (we should upstream that fix), you can just run tutor mounts add opaque-keys, then from within your cms container make sure to run pip install -e /mnt/opaque-keys after checking out the correct branch, to refresh the entry points.
  2. Run tests.
    • tutor dev exec cms bash
    • DJANGO_SETTINGS_MODULE=cms.envs.tutor.test pytest openedx/core/djangoapps/content_libraries/ openedx/core/djangoapps/content/search/tests/ -x

Status

  • Create units
  • Set a "friendly" slug based on the title.
  • Read units
  • Generate a search index document for units
  • Build was entirely green as of 9383d5f
  • Add units/containers to the search index automatically when a new unit is created
  • Include units/containers when rebuilding the entire search index via reindex_studio command.
  • Rebase after refactor: convert content libraries python API from attr.s to dataclass, fix types [FC-0083] #36381 has merged
  • Address TODOs added here, where possible
  • Merge blocking PRs and update this accordingly

Out of scope for now:

  1. Update and Delete will be done in a follow-up PR: feat: adds APIs to update or delete a container open-craft/edx-platform#757
  2. Anything involving children / components in the unit.

Deadline

ASAP

Private ref: FAL-4052

@openedx-webhooks
Copy link

Thanks for the pull request, @bradenmacdonald!

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.

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.

@openedx-webhooks openedx-webhooks added the open-source-contribution PR author is not from Axim or 2U label Mar 12, 2025
@bradenmacdonald bradenmacdonald mentioned this pull request Mar 12, 2025
Open
@bradenmacdonald bradenmacdonald force-pushed the braden/units-api branch 4 times, most recently from de946eb to 55d9b34 Compare March 14, 2025 02:21
This was referenced Mar 14, 2025
Closed
Merged
@bradenmacdonald bradenmacdonald force-pushed the braden/units-api branch 5 times, most recently from 40f8988 to ec7c500 Compare March 14, 2025 22:09
@bradenmacdonald bradenmacdonald mentioned this pull request Mar 14, 2025
Merged
kdmccormick
kdmccormick requested changes Mar 20, 2025
View reviewed changes
Copy link
Member

@kdmccormick kdmccormick left a comment •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Over on the opaque-keys PR, I was assured that LibraryContainerLocators did not need to be UsageKeys 😄 But on this PR, I see that we're calling them usage_keys in various places.

We need to be consistent. Either these are not usage keys and we shouldn't call them as such, or they are usage keys and we should update opaque-keys to make LibraryContainerLocator explicitly subclass UsageKey.

@ormsbee
Copy link
Contributor

ormsbee commented Mar 20, 2025

Would it be simpler to just use the container UUIDs in the REST API, instead of keys?

@pomegranited
fix: rename api method to library_container_locator
7081488 
since container keys are locators, not usage keys
@pomegranited
Copy link
Contributor

@kdmccormick

Over on the opaque-keys PR, I was assured that LibraryContainerLocators did not need to be UsageKeys 😄 But on this PR, I see that we're calling them usage_keys in various places.

We need to be consistent.

Agreed -- please see 7081488.

Note that I chose to leave the container search document usage_key field named as such, so that its document format closely matches the collection document, which keeps the frontend code simpler. Let me know if that's not ok.

@pomegranited
Copy link
Contributor

@ormsbee

Would it be simpler to just use the container UUIDs in the REST API, instead of keys?

Currently, we're slugifying the user's provided title and passing it to create_container as key=slug. So that slug becomes the publishable entity key. I think that using this slug makes for a much nicer URL for the REST API than the UUID would, e.g. http://studio.local.openedx.io:8001/api/libraries/v2/containers/lct:OpenCraft:FAL-4054:unit:unit-1-4a4646/

If we're going to use the UUID in the LibraryContainerLocator instead of the slug, then I don't think there's any reason to slugify the title either, but will do it whichever way you think is best.

@pomegranited pomegranited mentioned this pull request Mar 21, 2025
Open
@navinkarkera navinkarkera mentioned this pull request Mar 24, 2025
Open
@ChrisChV ChrisChV mentioned this pull request Mar 26, 2025
Draft
@pomegranited pomegranited mentioned this pull request Mar 26, 2025
Merged
@pomegranited
Copy link
Contributor

Hi @kdmccormick and @ormsbee -- could you have another look at this PR to see if I've addressed your concerns here?

kdmccormick
kdmccormick approved these changes Mar 26, 2025
View reviewed changes
Copy link
Member

@kdmccormick kdmccormick left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not a thorough review, but my concern is resolved, so 👍🏻

If you want me to test and review thoroughly, let me know and I can do that!

@pomegranited
Copy link
Contributor

Thanks @kdmccormick ! cf e0f4380

If you want me to test and review thoroughly, let me know and I can do that!

I'm happy with @rpenido and @navinkarkera 's reviews, but thank you for offering. I've got some follow-up work to do here in later PRs though, so if there's anything bugging you, please let me know :)

@pomegranited pomegranited mentioned this pull request Mar 27, 2025
Draft
@ormsbee
Copy link
Contributor

ormsbee commented Mar 27, 2025

@pomegranited: I'm good with trusting your existing reviewers on this. Thank you.

@pomegranited
feat: adds APIs to update or delete a container (#757)
1ef3b1e 
* feat: adds python and REST APIs to update a container's display_name
* refactor: adds _get_container method to api to reduce code duplication
* feat: adds python and REST APIs to delete a container
* test: add container permission tests
@pomegranited
Merge remote-tracking branch 'origin/master' into braden/units-api
6686902
@navinkarkera navinkarkera merged commit 1ca57ec into openedx:master Mar 28, 2025
49 checks passed
@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.

1 similar comment
@edx-pipeline-bot
Copy link
Contributor

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

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

1 similar comment
@edx-pipeline-bot
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@rpenido rpenido rpenido approved these changes

@pomegranited pomegranited pomegranited left review comments

@ChrisChV ChrisChV ChrisChV left review comments

@kdmccormick kdmccormick kdmccormick approved these changes

@navinkarkera navinkarkera navinkarkera approved these changes

Assignees
No one assigned
Labels
FC Relates to an Axim Funded Contribution project open-source-contribution PR author is not from Axim or 2U
Projects
Contributions
Status: Done
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
10 participants
@bradenmacdonald @openedx-webhooks @ormsbee @pomegranited @edx-pipeline-bot @rpenido @kdmccormick @navinkarkera @ChrisChV @mphilbrick211