Create a command to import person from a csv file
I am currently working on a command to import people from a csv file.
Features I am currently trying to write :
- the first line of the CSV determines the information collected (firstname, lastname, ...). The column name may be set by an option. Example :
--firstname="Prénom". If no option is set, a default is used.
- currently, I only need to import Firstname, Lastname and Birthdate. We will have to think about other fields later (Nationalities, ...)
- the importer can understand localized date. For the date, you can pass one or more filters, using strptime. You can separate possible filters with a pipe. Example:
--birtdate_format="%d/%m/%y|%d/%m%Y"(a default is provided). The first format which match a format is considered.
Importing custom fields
For importing custom field, I am planning to ask the user interactively to map the column name with a custom field. Those questions should be asked :
The cli: We would like to map the column 'Logement actuel', do you want to match it to a custom field ? (Y,n) The user : Y The cli: To which question do you want to match the column 'Logement actuel' ? //here we list all existing custom fields which were not mapped before) 1. Situation sociale 2. Envoyé par ... 3. Situation de logement 4. En ordre de cotisation ? What is your answer ? The user : 3
For multiple choices during the parsing of the CSV, the cli will ask the user to which answer he wants to map the content of the column. The cli will keep in memory the answer, to ask only for one type of answer. Example :
The cli: I cannot map this content "Locataires" to one of those possible answer. Please pick amongst the possible values : 1. Propriétaire 2. Locataire 3. Sans logement 4. Chez des amis 5. Autre (other answer possible) To which answer should I map "Locataires" ? The user : 2. The cli: Thanks, I will map the content "Locataires" to the answer "Locataire" for the next possible answers.
Instead of manipulating a
Person object, I am thinking about manipulating a
PersonType form. I think this will make easier to pick the possible answer using this. This could also (but I am not sure) limit the amount of work to adapt a new customFieldType to processing it : instead of creating a processCustomFieldNumber, processCustomFieldText, processCustomFieldICPC2 etc. function, we could only process the form (a select, an input, ...) which should remains more limited.
What do you think ?