Developer Area/Import//Export/LEAP Import/Resume Artefact Plugin
From Mahara Wiki
< Developer Area | Import//Export | LEAP Import
The resume artefact plugin hooks into the LEAP import system to import resume data.
Import Strategies Provided
This plugin provides several strategies to import various entries, largely centering around identifying abilities, achievements and entries in life_area:Education or life_area:Work.
Some entries can't be identified without using Mahara's artefactplugin element. The spec doesn't allow us to distinguish between them because they're not actually decent pieces of data by themselves. Mostly, this applies to the WYSIWYG fields: cover letter, interests, skills and goals.
We can identify achievements, and assume that they are certifications. There is a complication with this. When an education history record is exported, it also includes an achievement entry that represents the qualification obtained. At import time, we want to associate this back with the education record, so achievements aren't given a high score in themselves. They get a high score if we look at the artefactplugin element and see that they are of type psuedo:certification - then we know for sure that they used to be certifications.
Activities in life_area:Work are considered to be parts of employment history, and can have a supporting organisation. Resources of resource_type:Printed are considered to be books, and can be supported by an achievement, which is considered to be the user's role with regards to the book (e.g. author, reviewer). Activities in life_area:Education are considered to be education history, and can both support an achievement, and be supported by an organization.
Our concept of professional membership can't be represented reasonably in LEAP2A currently, so for now it's just detected by looking at the artefactplugin element.
How Entries are Imported
Once the entries have been identified, stitching them together into resume artefacts is relatively simple. There are two slight complications:
- We have to be careful about how we deal with dates - Mahara doesn't store them as dates, they're just text. So a method handles parsing the dates we get from the entries, and converting them to text form
- In order to preserve the display order of the entries, we look for the Mahara custom selections in the file, and get the ordering from those. The reason for just looking at those is because entries can be in any number of selections, and we want to make sure we get the ordering from the right place. That is the only use for those selections when importing into Mahara - they're discarded once the import is done.