Proposals/Done/Portfolio Export Import

Moving from one Mahara installation to another

The Leap2A export option of Mahara allows users to export their portfolios in such a fashion that they can be imported into another Mahara instance of the same version or higher. If the exporting Mahara instance was customized, e.g. included plugins that are not available on the receiving Mahara, then that portfolio content cannot be displaye properly.

Improving the export and import of portfolios

Making the export and import of portfolios easier becomes more important as more users have Mahara experience and may wish to move their portfolios from one site to another. That also means that the portfolios contain data and can be large, e.g. 1 GB of file quota, if Mahara installations allow for large portfolios.

Load issues with larger LEAP2A files

• Exporting large portfolios (> 100 MB) results in a large server load and the export process frequently times out.
• Importing large portfolios (> the allow maximum file upload) so far always needs a temporary adjustment on the server side.

Solutions

• The time out needs to be set higher to avoid time outs during the export of large portfolios.
• Make the export of portfolios time delayed so that the load can be spread more evenly over the server and does not, for example, run while the site is in heavy use. A user could receive an email once his portfolio export file is available for download. Include a message that tells the user for how long the export file will be available before it will be deleted.
• The administrators should be allowed to upload Leap2A files that are larger than the allowed maximum file upload size for users to be able to import portfolios easily.

User self-import of LEAP2A

Currently (Mahara 1.7), the only LEAP2A import functionality in Mahara is that an admin can import a LEAP2A file and create a new user account from it. It would help out with portability, though, if users could import their own LEAP2A files, either at self-registration time, or after they've created their account (in order to add content to their account).

Leap2A import during self-registration

• During the self-registration process, a user should be allowed to upload a Leap2A file and create their account based on its content.
• Note there may be file size issues involved with Upload of large Leap2A's
• During the upload process, the zip file should be checked for whether it contains a Leap2A xml file. If that is not the case, the import is aborted.
• Uploads older than a couple of hours (perhaps because the page crashed so they didn't get properly deleted after being processed) should be deleted from the system, maybe by a cron job
• Most new users will not be importing a Leap2A file. So, we shouldn't put the upload form directly on the registration page or it'll just confuse people
  • Instead, there should be a link on the registration page that says "Import a Leap2A file", and clicking on that will take the user to a different page or display the upload form

Leap2A import into an existing Mahara account

Allowing import of Leap2A into existing Mahara accounts helps with these use-cases:

• Users who want to import their account into a site that doesn't allow self-registration
  • They can do a Leap2A import after they log in
  • So perhaps on the first login of a new account, the Leap2A import page should be highlighted?
• Import/export of Pages & Content from another Mahara site

Here's some notes on how import into an existing account should work:

• A user is allowed to import Leap2A files into their existing account at any time
  • There should be an "Import" tab, like the existing "Export" tab.
  • The Leap2A may be partial (just a few pages / collections)
  • Or the Leap2A may be full (with user profile information)
• Content & pages should be copied into the user's account. We won't make any effort to determine if duplicates of the data already exist in the account.
  • Bonus points for displaying a listing (or a preview) of the contents beforehand, and providing a checkbox for each so the user can decide to include or exclude it.
  • Bonus points for grouping the file artefacts into a new directory (perhaps based on the name of the Leap2A file)
  • Bonus points for putting the pages into a new Collection (once we implement allowing Pages to belong to multiple Collections) so the user can consider them in isolation easier.
• Profile & Resume data, the user will have to decide whether to replace, ignore, or merge the data with their existing profile & resume, where appropriate
  • The easiest implementation is simply to give the user a radio button with a choice of ignore or replace, which will apply to all the fields at once
    • But locked fields that the user can't edit, will be skipped over
  • Bonus points for providing a listing of all the profile & resume items in the Leap2A
    • Better still to put controls next to each item so the user can make a decision on each one whether to ignore, replace, or merge
      • Merging would be for fields where the user is allowed to have more than one value (for instance, additional email addresses, work history, etc). This would mean you add the Leap2A values to the end of the list. (Possibly you also check to make sure you don't add duplicates of existing data)
      • Locked fields should be displayed, but have the controls grayed out and a note saying that field is not user-editable so it'll be ignored.
    • Better still to put a preview of the contents of each item, with a side-by-side view so you can compare the Leap2 content and the existing content, and decide whether to ignore/replace/merge based on that
• The Profile Page is a special case
  • We will have to let the user decide whether to make the Leap2A file's Profile Page into their new Profile Page, or whether to copy it into a normal Page.
  • If we're allowing users to make decisions about how to import each individual item, then the user should be able to choose to ignore the Profile Page, replace their existing Profile Page with the new one (demoting their existing Profile Page to a normal Page), or copy the Leap2A Profile Page into a normal Page.
• Collections in the Leap2A will simply link to the newly copied Pages from the Leap2A
• If you replace or update Profile & Resume artefacts, all blocks referring to the user's Profile & Resume artefacts should be seamlessly updated with the new data
  • As an implementation question we'll need to look at how those blocks are implemented, and possibly update them to point to the new artefacts
• In keeping with Mahara's pluggable nature, it may be appropriate to have each Artefact plugin make decisions about whether it can be replaced or copied or merged, about how it should be previewed, etc.
  • Where possible we should re-use existing code for the preview functionality (i.e., if there's a function in the Artefact that gets called to display the Artefact, then call that for the Preview. Or if some ARtefacts might need to display differently in preview mode, then provide an Artefact->Preview function in which the default implementation is just a pass-through call to the normal Artefact display function)

Filed the following related bug

(encountered during manually merging of two accounts and uploading of files via a zip archive)

Not all file types are correctly identified after uploading a zip archive: https://bugs.launchpad.net/mahara/+bug/803229 (only related in so far as if user uploads a bunch of his files manually via a zip archive)