feat: allow block publish if was published before Library v2 migration by asadali145 · Pull Request #38865 · openedx/openedx-platform

asadali145 · 2026-07-09T10:25:27Z

Description

This PR adds the ability to publish a library content block if it was published before the V2 migration. This would be helpful for anyone having too many courses and libraries.

Testing instructions

Checkout mater branch
Create a legacy library and use it in a course.
Go to the content -> library update -> Review content updates and update the library references.
Go to the Unit with library content and notice that it is in draft.
Now checkout this branch and update the falg defaults to True and repeat the above steps. It should publish the block.

openedx-webhooks · 2026-07-09T10:25:33Z

Thanks for the pull request, @asadali145!

This repository is currently maintained by @openedx/wg-maintenance-openedx-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.

asadali145 · 2026-07-09T15:27:09Z

@arslanashraf7 this should be good for another look.

arslanashraf7

👍

pdpinch · 2026-07-13T12:26:06Z

Does this need Product review? I feel like @jmakowski1123 told me once that there was some concern about having blocks published as part of the migration process.

asadali145 · 2026-07-13T12:36:15Z

Does this need Product review? I feel like @jmakowski1123 told me once that there was some concern about having blocks published as part of the migration process.

@pdpinch, we are not changing the default behavior. It is still the same after the changes.

I would like to know more about the concerns about publishing the migrated blocks.

ormsbee · 2026-07-14T15:30:53Z

Also FYI @kdmccormick

kdmccormick

I can see the value in reducing number of clicks authors need to do in order to migrate, but I am wary of introducing a bug by publishing in non-standard way.

kdmccormick · 2026-07-14T15:59:08Z

        from cms.djangoapps.modulestore_migrator import api as migrator_api
        store = modulestore()
        with store.bulk_operations(self.course_id):
+            was_published = persist_publish_state and store.has_published_version(self)


I think this will check if there is any published version, not whether the current version is published, right?

def has_published_version(self, xblock): """ Returns whether this xblock has a published version (whether it's up to date or not). """ return self._get_head(xblock, ModuleStoreEnum.BranchName.published) is not None

Yes, that's right. Let me update it to check the current version is published.

I have updated the PR and used has_changes to detect if there are any draft changes.

kdmccormick · 2026-07-14T15:59:25Z

            self.save()
            store.update_item(self, user_id)
+            if was_published:
+                store.publish(self.location, user_id)


@ormsbee Is there prior art for publishing a single course component rather than a unit?

The only reason behind not publishing a unit was that a unit can contain draft and published blocks.

Not that I'm aware of, though I think it should work. We do auto-publish some standalone HTMLBlock sub-types like for course-tab content.

kdmccormick · 2026-07-14T15:59:55Z

 @shared_task(base=LegacyLibraryContentToItemBank, bind=True)
-def migrate_course_legacy_library_blocks_to_item_bank(self, user_id: int, course_key: str):
+def migrate_course_legacy_library_blocks_to_item_bank(
+    self, user_id: int, course_key: str, persist_publish_state: bool = False,


what code would ever specify persist_publish_state = True?

The idea is to provide a management command to do this.

ah, would the management command be an alternative to migrating the legacy library references from within the Studio UI?

could you describe the proposed CLI a bit more?

When I explored the code around migration, I saw replace_v1_lib_refs_with_v2_in_courses. It looked like it should do what the migration API does when we call from the authoring MFE, but this command replaces the existing field references with V2, and that field is not even compatible with V2 Library locator. I don't know why it still exists there.

Then I found the API, and it had this publishing issue. My idea is to keep the current API as is (Keep the blocks in draft). Create a new command that does the same but also provides an optional argument to publish the blocks using this flag. So, for people who really know what they are doing, they can use this command.

Another option is to maybe give another button in the authoring MFE that hits the same API but also publishes the blocks using this flag.

Let me know what you think of the 2 options, and I can create a follow-up PRs or maybe if we go with the command then I can add it in this PR.

openedx-webhooks added the open-source-contribution PR author is not from Axim or 2U label Jul 9, 2026

openedx-webhooks added this to Contributions Jul 9, 2026

github-project-automation Bot moved this to Needs Triage in Contributions Jul 9, 2026

asadali145 force-pushed the asad/v1-v2-lib-migration-fixes-and-command branch from 4db4e90 to 4f8a913 Compare July 9, 2026 10:30

asadali145 marked this pull request as ready for review July 9, 2026 11:12

asadali145 requested review from farhan, irtazaakram and salman2013 as code owners July 9, 2026 11:13

arslanashraf7 suggested changes Jul 9, 2026

View reviewed changes

Comment thread cms/djangoapps/contentstore/tasks.py Outdated

Comment thread xmodule/library_content_block.py Outdated

Comment thread xmodule/tests/test_library_content.py Outdated

asadali145 force-pushed the asad/v1-v2-lib-migration-fixes-and-command branch from 4f8a913 to b59b9e4 Compare July 9, 2026 15:25

asadali145 requested a review from arslanashraf7 July 9, 2026 15:26

asadali145 force-pushed the asad/v1-v2-lib-migration-fixes-and-command branch from b59b9e4 to 1962ae8 Compare July 9, 2026 15:26

asadali145 mentioned this pull request Jul 9, 2026

feat: command to migrate v1 to v2 lib references mitodl/open-edx-plugins#825

Open

arslanashraf7 approved these changes Jul 10, 2026

View reviewed changes

mphilbrick211 moved this from Needs Triage to Ready for Review in Contributions Jul 13, 2026

kdmccormick requested changes Jul 14, 2026

View reviewed changes

feat: allow block publish if was published before Library v2 migration

3b9c887

asadali145 force-pushed the asad/v1-v2-lib-migration-fixes-and-command branch from 1962ae8 to 3b9c887 Compare July 14, 2026 16:38

Uh oh!

Conversation

asadali145 commented Jul 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Testing instructions

Uh oh!

openedx-webhooks commented Jul 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

asadali145 commented Jul 9, 2026

Uh oh!

arslanashraf7 left a comment

Choose a reason for hiding this comment

Uh oh!

pdpinch commented Jul 13, 2026

Uh oh!

asadali145 commented Jul 13, 2026

Uh oh!

ormsbee commented Jul 14, 2026

Uh oh!

kdmccormick left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

asadali145 commented Jul 9, 2026 •

edited

Loading

openedx-webhooks commented Jul 9, 2026 •

edited

Loading