Able to import a course built using the framework

[dancgray]

It would be very useful to be able to import a course developed in the framework.

This could be done from either a zipped built course or using a task to convert a framework course to the format used in import.

The first option makes the most sense but could be harder to implement without altering the framework build task.

[aniketdharia]

@dancgray JSON can be managed using the build folder. I think this should be enough. If there are any other modifications done, like theme or custom extensions, they can be imported separately and then added to the course manually.

But if they are already existing, we can add them while importing itself.

[P.S. I am not sure yet how to use course jsons to find the right extension]

[dancgray]

@aniketdharia I agree that importing from the build folder would be ideal. However there are a number of requirements in the import/export ticket that make this difficult.

Specifically:
IMEX-013: Ability to flag incompatibilities with the JSON of my course and the AT instance it is imported into (e.g. version incompatibilities) - Although this ticket would help.

IMEX-017, IMEX-018, IMEX-019, IMEX-020: ability to make custom components, extensions, themes and menus available in the authoring tool.

Maybe we could have an import light (JSON & assets only) and reject the import if not all plugins (of the right version) are pre-installed in the authoring tool. @aniketdharia @taylortom what do you think?

[dancgray]

OK, some progress is being made on this. Bit of an issue when dealing with images though. Any suggestions welcome.

The problem is creating the courseassets collection in the authoring tool from the framework JSON on import. courseassets collection is essentially reference data linking assets with each usage of that asset by a plugin within course, article, block or component JSON.

So for every asset used in the course JSON I need to create a courseassets document.

To do this I'm proposing to use the assetFields values from each plugins bower.json. So for each article/block/component imported we would loop through all of the included plugins with assetFields looking for assets matching the keys in assetFields. Any found would be inserted into courseassets with appropriate values for assetId, parentId etc.

So my questions are:

1. Is this a sensible approach?
   Problems are:
   The assetsFields value in each plugin would need to be updated/maintained and the plugin released again as they are not all correct.
   Framework import will only work with plugin versions that have an up to date bower.json.

2. Do we have to transform the asset file name to a GUID on upload?
   As this means I need to update all ABC JSON asset references as well as create a document in courseassets. Much simpler to just upload the asset. As the GUID naming hash function is deterministic the asset file gets overwritten anyway on any collisions.

[brian-learningpool]

Hi @dancgray, in my opinion the courseassets collection could be done away with completely if the build/output process were tweaked accordingly. If you think about it the only thing you need to be aware of is "Is this asset a part of the course?" and with the relative URLs, i.e. /course/hashedfilename it's already known.

All the information relating to parentIds, etc. is pretty inconsequential in the current version of the authoring tool, in much the same way as the assetFields property is no longer required with the Backbone Forms asset inputType.

[dancgray]

@brian-learningpool, don't you have the same problem of having to parse through the course JSON for anything that might be an asset. i.e any string in a field that matches a file regex?

Does not sound ideal. Might have misunderstood what you intended though.