Open connorhaugh opened 1 year ago
@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
@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?
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.
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...
Like course import/export, but for libraries! AC:
Notes What is the file format of v2 library packages? Does it need to be similar to v1 library packages?
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.