Mapping api does not support a name in mapping_type_id

[eileenmcnaughton]

I've been trying to use apiv4 but have hit that this

CRM.api4('Mapping', 'create', {
  values: {"name":"mapping", "mapping_type_id":'Import Contact'}

Does not look up the mapping_type_id from the passed in name but instead saves it with a 0, despite the metadata being defined.

Digging through the code I can't see where the support is for passing in name instead of id.... please tell me apiv4 does support names...

[colemanw]

... no it does not... yet. I was working on that when https://github.com/civicrm/civicrm-core/pull/13907 got stalled and I'm still mulling over the best way to do it. Api4 is more precise and literal about things, so I think it would be more proper to say 'mapping_type_id.name' => 'Import Contact' (appending the .name because we are not actually passing in the id, rather than relying on "magic" inside the api to figure out what we meant).

But not all pseudoconstants have names, and some have multiple ways to identify them, so should we also support .label or state_province_id.abbreviation or other things. That's where I got bogged down.

[eileenmcnaughton]

@colemanw so I'm working on some importing at the moment (which has had me delving into import code although we are mostly not going to use the core import) & I have a couple of observations on this.

Basically what we get is a scenario where there may not be consistency over the data - so to take country the csv could have a mix of names, ids & & iso_codes whereas for a custom field there might be a combo of labels & names. Where we are with the existing import UI is (inconsistently) a matching hierarchy ie -> does it match the id? Use that -> does it match the name? Use that -> does it match the label

which is a pain from a dev POV but really good for importers

It feels like something like 'mapping_type_id.match' => 'Import Contact' would be really useful - although we have the issue that .match hardly fits your patterns