Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Various fixes to contact types, interaction with contacts, and contact type forms:
The main issue was primary fields were not being saved to config, and field config was not being fetched from Drupal API correctly.
Also available from GH dpi/crm_core/contact-type-primary-fields
Notes:
- Changed schema since its current usage assumed sequence was a KV, instead the keys were being destroyed on save.
- Fixed missing contact type interface extend.
- Added a getPrimaryField method to ContactType entity.
- Converted getPrimaryField on Contact entity to use getPrimaryField method instead of raw class properties.
- Changed primary field container to 'details', since thats what a lot of Drupal is using. Also the description mentions 'the fields below' except the description was being rendered below the fields. Changing to details fixes this.
- Fixed call to getFieldDefinitions. Looks like the Drupal API changed since this was written as its usage was completely nonsensical.
- Changed empty_option label to remove 'Please'. We don't add emotion to text in Drupal.
- Primary fields values are now saved to the config.
Comment | File | Size | Author |
---|---|---|---|
#6 | 2711935-6-contact-type-primary-fields.patch | 7.56 KB | grahl |
contact-type-primary-fields.patch | 6.21 KB | dpi |
Comments
Comment #2
dpiPatch is required for https://github.com/dpi/courier_crm_core_contact
Comment #3
BerdirSure about this? These are the only possible primary fields?
The documentation doesn't seem to indicate this, a sequence for any list of field seems more likely?
Also, given that we plan to add multi-value fields with a type for email and phone, I'm not sure if this API will still be required then?
If null is a valid return value, shouldn't we check that? this will throw a veird exception otherwise.
inheritdoc can only be used if it's the only thing, if you extend it, you have to copy the parent implementation.
Looks like there are supposed to be more of those primary fields, it's just commented out at the moment.
Comment #4
dpiI discussed the future of contacts and contact types with miro_dietiker over IRC this morning and I understand this patch is likely obsolete since the model is changing.
email, address, primary they are the primary fields listed in the UI, and there's an array on the form which has those fields. Again I understand the existing implementation was probably placeholder. If the model allowed more primary fields then the schema will be very different.
I dont think what I have written will stick, but it gets the existing code running.
Comment #5
grahlProbably irrelevant, need to check.
Comment #6
grahl- Primary fields schema potentially still relevant but leaving out to leave the option of adding additional fields in custom code.
- ConfigEntityBundleBase already provides ConfigEntityInterface, not needed
- Primary Fields functions already present, however the function does two things: get the field name and field value, let's take that apart.
And let's add those functions to the interface.