-
Notifications
You must be signed in to change notification settings - Fork 4.3k
feat: allow block publish if was published before Library v2 migration #38865
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
base: master
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -329,14 +329,18 @@ def studio_post_paste(self, store, source_node) -> bool: | |
| self.sync_from_library(upgrade_to_latest=False) | ||
| return True # Children have been handled | ||
|
|
||
| def v2_update_children_upstream_version(self, user_id=None): | ||
| def v2_update_children_upstream_version(self, user_id=None, persist_publish_state=False): | ||
| """ | ||
| Update the upstream and upstream version fields of all children to point to library v2 version of the legacy | ||
| library blocks. This essentially converts this legacy block to new ItemBankBlock. | ||
|
|
||
| If `persist_publish_state` is True, and this block was published prior to the migration, it is | ||
| re-published afterwards so that the upstream/upstream_version changes reach LMS. | ||
| """ | ||
| 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 not store.has_changes(self) | ||
| children = self.get_children() | ||
| # These are the v1 library item upstream UsageKeys | ||
| child_old_upstream_keys = [ | ||
|
|
@@ -358,6 +362,8 @@ def v2_update_children_upstream_version(self, user_id=None): | |
| self.is_migrated_to_v2 = True | ||
| self.save() | ||
| store.update_item(self, user_id) | ||
| if was_published: | ||
| store.publish(self.location, user_id) | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @ormsbee Is there prior art for publishing a single course component rather than a unit?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The only reason behind not publishing a unit was that a unit can contain draft and published blocks.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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. |
||
|
|
||
| def _validate_library_version(self, validation, lib_tools, version, library_key): | ||
| """ | ||
|
|
||
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.
what code would ever specify
persist_publish_state = True?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.
The idea is to provide a management command to do this.
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.
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?
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.
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.