[V2 Content Libraries] V2 Library Import/Export

[connorhaugh]

Like course import/export, but for libraries!
AC:

• v2 Library Authoring experience must support import of a package that contains: Either a v1 library or a v2 library
• v2 Library Authoring experience must support export of a package that contains: a v2 library
• NOT IN SCOPE: exporting v2 libs as v1 libs.
• NOT IN SCOPE: importing existing v2 libs that the user can read
• Make a REST API that T&L can consume to build the feature in the library-authoring MFE. Try to make it similar enough to the course import/export API that it would be easy to reuse Course Authoring MFE import/export work here.

Notes
What is the file format of v2 library packages?
Does it need to be similar to v1 library packages?

• Kyle could sketch out some formats as an AC for this
• Brad will work with partners to get information about what makes a file format good, but this will be a hard question.
  Compatibility with partial import export work, if work could be reused for partial import export work, IDK if we could reuse stuff here
  What info should be in and out of the package?
  Versioning: Are there ways to make the current course -> library linkup on course import across instances or more straightforward?
  We are ok with the solution from an experience perspective already, but there is room for improvement?
  How do library-specific permissions work with exports and imports?
  Do we need to call out that import is from v1 or v2 to the user?

I see several tasks here:
Determine a format/spec for v2 lib exports.
Create the library export page (Less of a priority for Kyle, as we have Ken focused on MFE work, and mocks forthcoming).
Write the export celery task
Write the import from v2 celery task
add the logic to handle imports of courses, v1 and v2 libs.

[connorhaugh]

@kdmccormick for your arrival:
In terms of feedback from Brad, the main point of emphasis for

what makes a file format "good"

and

should importing a library + course to another instance make them automatically linked

and

Should import/export work export/import permissions

and

Should this work be compatible with import/export?

Is to keep it simple and extensible. We haven't been able to generate enough feedback about this feature to develop strong opinions without user interacting with it first. Getting a MVP without these "nice to haves" to prod should be the main goal. From there, TNL can iterate on your work where we see value. Thanks, hope that clarifies things

[kdmccormick]

@connorhaugh what do you mean by these?

from the description:

NOT IN SCOPE: importing existing v2 libs that the user can read

from your latest comment:

Should import/export work export/import permissions

Should this work be compatible with import/export?

[ormsbee]

Product question (@jmakowski1123): Does it make sense for us to have separate import/export mechanisms for the editing vs. backup/restore/copy-to-other-instance use cases?

With courses, we import and export the draft and published branches only. This works fine for both the edit-in-Github use case and the backup/restore/copy-to-other-instance use cases. But v2 content libraries will have a lot more information in them, like a publish history and per-component version identifiers. This is going to be especially true if we start pinning things inside of it, e.g. "this Unit is using these versions of these components", but is something that will potentially bite us even in the case where we're importing courses that reference specific versions of content in a library that's been copied from another server.

One idea I've been fiddling with is to have two types of import/export. The first would act much like it does with courses–an archive of XML files and static assets that represents a snapshot of the current state. The second would export an actual database file that has all the more complicated version and relationship data. The latter would not be human-readable, but would give full fidelity backup/restore functionality, and carry over all version information into any new instance.

[jmakowski1123]

Product question (@jmakowski1123): Does it make sense for us to have separate import/export mechanisms for the editing vs. backup/restore/copy-to-other-instance use cases?

With courses, we import and export the draft and published branches only. This works fine for both the edit-in-Github use case and the backup/restore/copy-to-other-instance use cases. But v2 content libraries will have a lot more information in them, like a publish history and per-component version identifiers. This is going to be especially true if we start pinning things inside of it, e.g. "this Unit is using these versions of these components", but is something that will potentially bite us even in the case where we're importing courses that reference specific versions of content in a library that's been copied from another server.

One idea I've been fiddling with is to have two types of import/export. The first would act much like it does with courses–an archive of XML files and static assets that represents a snapshot of the current state. The second would export an actual database file that has all the more complicated version and relationship data. The latter would not be human-readable, but would give full fidelity backup/restore functionality, and carry over all version information into any new instance.

We'd have to really think through the UI experience for users. I think it would be confusing to have a choice to make about which import/export an end user needs. It sound like a "lite" version and a "full" version. But communicating when it's appropriate to choose one over the other could create a lot of confusion...