Requirements - Libraries support Library-Library export and restore (backup and restore)

Value Proposition: 

In the Legacy Libraries experience, it is possible to export full libraries, and re-import them. As we move toward deprecating the Legacy Libraries feature, it’s important to ensure that the new Libraries experience maintains parity with the export/import feature. This ensures that users do not lose functionality when they move from the legacy environment to the new one. It also adds options for flexibility and security as organizations plan for potentially large-scale content migrations. Finally, it enables backup, archiving and restoring when needed.

User stories:

As a library administrator of V1 Libraries:

• I have thousands of V1 libraries, and I don’t need to migrate all of them to the V2 environment at once, or I may want to decide which ones I’ll need later. I plan to export all of my V1 libraries and archive them locally, and I expect that if/when I may need them later, I’ll be able to import the files into the new Library environment.

• I want to backup and archive my V1 Libraries, so if something goes wrong during the migration process, I have copies that I expect to be able to import into the new Library environment.

As a library administrator or library author of V2 Libraries:

• I want to export my V2 library so I can save my work.

• I want to backup and archive my work locally, using my institution’s content management standards. 

• I want to share my Library with another staff member who works on a different Open edX instance at my institution. [noting that the approach to sharing a Library across instances via export/import is a temporary solution, until we build a more robust sharing feature, and not a use case we’ll want to actively highlight]

Iteration of sharing story - multiple production/testing environments

What’s the difference between V1 Library migrations and Library-Library export/import?

• Migrations are a temporary workflow to get users off the Legacy library environment as quickly as possible. It addresses tech debt and is a one-and-done workflow.

• Migrating legacy library can happen in bulk, and the goal is to get as many folks off the legacy environment as quickly as possible.

• Migration maintains course references, while importing an exported library file does not.

• Exporting libraries primarily fills a need for archiving, backing up, and restoring if necessary. It can be used for low-level sharing needs, but we plan to build a more robust feature-driven solution for library sharing in a future phase.

Requirements:

V2 Library support of V2 exports

• It is possible to export a V2 library and save it locally.

• When a V2 Library is exported, it includes any custom settings/metadata that have been configured on structural blocks.

• When a V2 library is exported, it maintains any collections that exist within the Library.

• When a V2 library is exported, it maintains any tags that have been added to content.

V2 Library support of V2 restore

• It is possible to take a V2 Library export file and restore it to a brand new library

• When a V2 Library is restored, it maintains any customizations/metadata that were made to structural blocks and components.

• When a V2 Library is restored, it maintains/rebuilds collections.

• When a V2 Library is restored, it maintains any tags that were added to the content.

• When a V2 library is restored, it must be done as a newly created Library. It is not possible to add a restored file to an existing library or to replace a library.

• When a V2 Library is restored, any links/course references are broken in the newly created library.

V2 Library support of V1 exports

• It is possible to take a V1 Library export file and import it into the new V2 Library environment. 

• [parity with V1 export/import] When a V1 Library export file is imported into the new V2 Library environment, the new library environment maintains any customizations that were made to problem settings.

• When a V1 library is imported, it must be done as a newly created Library. It is not possible to add an import to an existing library or to replace a library.

• When a V1 Library is imported, any links/course references are broken.

V2 Library support of V2 re-imports

• Re-imports are not supported.

MVP Permissions:

• Only Library administrators can export and import libraries. 

Out of scope now, possible to be added in future improvements:

• There is a separate epic to define more granular settings configurations at the unit, subsection and section level. Once those are defined, we may want to expand the scope of Library exports to include those settings.

• Partial export/import - possibly at the collection level

• More granular permissions - library authors can export libraries

UI Considerations:

• Instead of using “import/export” in two contexts (importing a course to a library, and library-library import), propose changing the latter to “backup”, “restore” or similar, and using “import” specifically for importing course content into a library.

• Course import to a library is a primary action, while backing up and restoring are secondary actions.

Timeline:

• Ulmo:

  • Manual migration UI from V1 to V2

  • Ability to export V2 libraries, primarily to fulfill the backup and archiving use cases

  • Ability to import exported files of V1 and V2 libraries, primarily to fulfill restoration use cases, and low effort sharing use cases

• Verawood:

  • Some solution to auto-migration from V1 to V2

  • V1 libraries moves to unsupported/depr

  • Discovery for a robust, fully-featured cross-organizational sharing feature