dev/core#5634 Add ImportTemplateField entity #31580
Conversation
|
🤖 Thank you for contributing to CiviCRM! ❤️ We will need to test and review this PR. 👷 Introduction for new contributors...
Quick links for reviewers...
|
|
The issue associated with the Pull Request can be viewed at https://lab.civicrm.org/dev/core/-/issues/5634 |
colemanw
force-pushed
the
importTemplateFields
branch
from
b41e84d to
734a3b9
Compare
colemanw
force-pushed
the
importTemplateFields
branch
from
734a3b9 to
0aadb92
Compare
| name: importRow.selectedField, | ||
| default_value: importRow.defaultValue, | ||
| // At this stage column_number is thrown away but we store it here to have it for when we change that. | ||
| column_number: index, | ||
| column_number: index + 1, |
There was a problem hiding this comment.
@eileenmcnaughton what does the above comment mean? I'm adding the +1 here to start the count at 1 instead of zero, but... it's thrown away?
There was a problem hiding this comment.
yeah - I think the underlying code just isn't looking at it
| <?php | ||
|
|
||
| return [ | ||
| 'name' => 'ImportTemplateField', |
There was a problem hiding this comment.
One thing I have been thinking about is adding transformations - which could be simple - eg 'upper' or they might be more complex. Part of me wonders if we should accomodate them in this table - although perhaps it would be a many to one joined table
There was a problem hiding this comment.
@eileenmcnaughton couldn't they be stored in the entity_data column in this table?
There was a problem hiding this comment.
@colemanw I guess so - the entity_data was originally about storing entity info - ie 'I have a related contact that might be created here - what is it's contact type if I have to create it' vs transformations which are field-specific. The name entity_date is not a great fit for the latter
There was a problem hiding this comment.
Yea it's confusing either way. E.g. why are we storing entity_data at the field level?
Maybe a more generic name for the column would serve better, like "settings" or "data"?
There was a problem hiding this comment.
@colemanw yeah - let's go with data
As to why - if you look to the contact import you can see you can have multiple rows that import to different entities - ie mother first name, father first name, mother home phone, father home phone
Really it should be a case of 'specifiy the entities we import to & then on each row specify which one is involved' - but I don't quite know how to move in that direction
There was a problem hiding this comment.
@eileenmcnaughton ok, I looked at that example, and this is all starting to make more sense. So basically our starting point is what I fondly call "the mismash", where the list of "Contact" importable fields includes a bunch of stuff that doesn't actually belong to the civicrm_contact table (phone, email, street_address, city, etc). And we have some hacks sprinkled around to create the mismash (mixing those into the list of importable fields) and then more hacks to untangle the mismash during the import and put things where they belong.
Aside from being messy, another problem with this model is lack of flexibility. The contact importer has a limited ability to also import related entities... as long as those entities are also contacts! And that limitation comes from the model of "flat list of fields". The UI and data model are amenable to importing related contacts because they share the same list of fields.
But what if we wanted to import related entities that are not contacts (activities, notes, etc)? We either have to add it to the mismash, or, as you said, make it a multi-step process where first you pick the entity and the "how is this thing related to the contact", and then you pick the field.
I think the way we move in that direction is by adding an entity column to this new table. That would be a good start.
There was a problem hiding this comment.
@colemanw I think we might need an entity & an identifier - ie entity would be 'Address' & identifier might be either some criteria like 'location_type=Home' OR a name that refers to some other place where those things are configured
There was a problem hiding this comment.
@eileenmcnaughton yea although for max flexibility we can just stick that stuff in entity_data aka data.
colemanw
force-pushed
the
importTemplateFields
branch
2 times, most recently
from
6427d59 to
eb99637
Compare
colemanw
force-pushed
the
importTemplateFields
branch
from
eb99637 to
0373769
Compare
Overview
Draft