Mapping field schema inadequate

I've been digging into the import code in the hope of applying a similar combination of Iterate by Month & Leap by Extension as we have recently done for export.

In the course of the export UI work we established that if we separated the building of the mapping out from the rest of the code then the form & the work engine only had to agree on that format to be upgraded separately. For export the format was pretty straight forward -ie. use the schema / api for MappingField & Mapping.

For import I've discovered a few issues with how the Mapping Fields currently store the import mappings

1. Labels - unlike the export fields, which sensibly store field names, the Import schema stores the field label into the 'name' field (obviously any renaming breaks it)

2. Soft credits = arg. The field mappings store this in the sort of way Cinderella's sisters got that slipper on... In the 'name' / label field the word 'Soft Credit' is stored. In the 'contact_type' field the identifier is stored (ie. contact_id, external_identifier, email). The 'soft credit type' can be configured via the UI but per #654 (closed) is never saved...

I think it would be good to agree if mapping_field is the right place to store mappings - I'm inclined to think it is - but if so we probably want to extend the schema to support soft credits - probably in a slightly more generic way than just adding 'soft_credit_identifier' & 'soft_credit_type_id'...

It's worth also noting some of the things the current import DOES do for a user since the temptation to just replace it wholesale (which I don't think removes the 'how do we map' question) needs to be balanced against what it needs to do

• allows a range of date formats in import csv
• allows importing to a range of related contacts fields
• allows importing soft credits with a range of match criteria
• supports varied match criteria - eg. external_identifier, email, contact_id & for contribution trxn_id, invoice_reference
• provides a range of dedupe options & rule
• provides a range of matching - e.g matches to labels, values, state abbreviations

Does not

• allow you to choose whether 'empty' overwrites or is ignored
• allow you to specify a column value (ie. for everything in this import I want the source to be 'my import 2019' - potentially only if blank or for all fields). This can be done in the csv but ... users.