Custom profile fields not included in order_profile field

What we'll need to do, is add another elseif

      elseif ($field->getType() === 'commerce_tax_number') {
        $data_definition = TaxNumberDataDefinition::create('tax_number')
          ->setLabel(t('Tax number'));
      }
      else {
        continue;
      }

If it's a `telephone` field, we can borrow this from the actual field definition:

    $properties['value'] = DataDefinition::create('string')
      ->setLabel(t('Telephone number'))

If it's a string field, same difference.

👍looks right, but patches generated by Intellij fail to apply, I can work on the tests. But applying this to your project should unblock you

Thanks @p4trizio. I wonder if there is a way to make this "smart", so we don't need a defined allowed list. On one hand, it makes it testable and guaranteed. On the other hand, it makes it a pain with unexpected results. Early on I didn't have time to find a pattern for "perfection." But some of these simpler field types might make it easier. Phone, Email, String all have the same data definition.

Hi,

I don't know if this is relatable to this issue or worthy of a stand-alone: there is discrepancy between the billing\shipping information returned by commerce_api - "/jsonapi/carts" - and the profiles returned by json_api - "/jsonapi/profile/customer".

The first gives e.g. for billing profile:

{
[...]
  "billing_information": {
    "data": {
      "address_book_profile_id": "100"
    },
    "address": {
      "country_code": "IT",
      "administrative_area": "MC",
      "locality": "MACERATA",
      "postal_code": "62010",
      "address_line1": "address",
      "organization": "Company",
      "given_name": "Name",
      "family_name": "Surname"
    },
    "field_email": {
      "value": "mail@mail.it"
    },
    "field_partita_iva": {
      "value": "11111111"
    },
    "field_telefono": {
      "value": "3333333333"
    }
  }
}

While the latter gives:

{
  [...]
  "attributes": {
    "drupal_internal__profile_id": 107,
    [...]
    "address": {
      "country_code": "IT",
      "administrative_area": "MC",
      "locality": "MACERATA",
      "dependent_locality": null,
      "postal_code": "62010",
      "sorting_code": null,
      "address_line1": "address",
      "address_line2": "",
      "organization": "Company",
      "given_name": "Name",
      "additional_name": null,
      "family_name": "Surname"
    },
    "field_email": "mail@mail.it",
    "field_partita_iva": "1111111",
    "field_telefono": "3333333333",
  }
}

Aka: commerce_api gives the value of the "extra" fields of the profile as object, while json_api as string.
What's more, commerce_api logically requires an object as value of the "extra-field" to patch the billing\shipping profiles and crashes with a simple string.

Considering that it may be necessary to access to both resources, this requires boilerplate code to adapt those two different "format".

I wonder if it could be possible - and sensible - to make commerce_api return the values as json_api does.

I was working on the same thing, but I did full datatype thing for telephone. Where you end up with

$data_definition = PhoneNumberDataDefinition::create('phone_number')->setLabel(t('Telephone number'));

but seems Patrizio solution also works, so probably extra abstraction I added is obsolete.

I'd privilege the approach from #10, although It could use some refactoring. Regarding the patch from #12, there's no reason to define a new datatype.

I confirm #10 works, but in my case I have a custom boolean field, which is missing in the list.

Added boolean field, based on #10

Previous one didn't work.

From #10, it seems like we're just missing having the else return the field item definition. Compound fields are the tricky ones which require serialization. Or maybe I was just around all around and we could have just used getItemDefinition.

Nevermind. One of the reasons was to prevent displaying all of the fields.

I tossed up a new idea in https://git.drupalcode.org/project/commerce_api/-/merge_requests/10. This excludes entity keys. It doesn't exclude all base fields as someone may implement a base field. And I don't like explicitly just checking FieldConfig.

I guess something is wrong with the code from the MR.

I applied the patch, and I have a field called "field_mobile" which is supposed to contain data, and currently returns NULL.

Oh... I think this is due to OrderProfileItemList.php that wasn't updated. :)

Went ahead and committed the patch.