[PP-1] Order's Adjustment can't be normalized and serialized

Thanks for the patch. Adjustment values are now getting displayed in API response after applying the latest patch from https://www.drupal.org/project/drupal/issues/2915705 → and then 2916252-66.patch.
But there was a waring after applying 2916252-66.patch.
Deprecated function: Return type of Drupal\commerce_order\Adjustment::getIterator() should either be compatible with IteratorAggregate::getIterator(): Traversable, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in include()
Updating 2916252-66.patch to remove the warning.
Change

  public function getIterator() {
    return new \ArrayIterator($this->toArray());
  }

to

  public function getIterator(): \ArrayIterator {
    return new \ArrayIterator($this->toArray());
  }

It should be \Traversable, not \ArrayIterator.

The last patch caused side-effects (e.g. price substract() method with adjustment).
I ended up extending Drupal TypedDataNormalizer class to support Ajdustment normalizer

namespace Drupal\my_module\Normalizer;

use Drupal\commerce_order\Adjustment;
use Drupal\Core\TypedData\TypedDataInterface;
use Drupal\serialization\Normalizer\TypedDataNormalizer;

class MyModuleAdjustmentNormalizer extends TypedDataNormalizer {

  /**
   * {@inheritdoc}
   */
  public function normalize($object, $format = NULL, array $context = []): array|string|int|float|bool|\ArrayObject|NULL {
    $this->addCacheableDependency($context, $object);
    $value = $object->getValue();
    // Support for stringable value objects: avoid numerous custom normalizers.
    if (is_object($value) && method_exists($value, '__toString')) {
      $value = (string) $value;
    }
    if ($value instanceof Adjustment) {
      $value = $value->toArray();
    }
    return $value;
  }
}

The attached patch works... However I don't think we can commit it as this means Commerce just provides a normalizer for the "Any" data type, which is used by other field types... which is a problem... But attaching the patch anyway..

Perhaps we could provide our normalizer, only if the core one introduced in #2915705: TypedData 'Any' can't be normalized to array if it stores an object → doesn't exist?

Actually, let's go with this patch... Which provides the "Any" normalizer conditionally in case it is not defined by the serialization module.

We were missing the test group (added that). But also suddenly not sure about the fix, whenever I don't skip the test methods defined by the base class, there seems to be an issue with the denormalization of the adjustments field... Also... now extending getSupportedTypes() from the normalizer as the previous approach :

  /**
   * {@inheritdoc}
   */
  protected $supportedInterfaceOrClass = Any::class;

is deprecated in D10.2. I'd need to double check when this change was introduced to see if we need ot raise the required core version... Since I'm not sure the issue is actually fixed... Putting this issue on hold for now.

@jsacksick re: #80, I can confirm that the patch in #77 fixes the issue for me on D10.3.0.

Patch #77 works fine with Drupal 10.3
Thank you

Last time I worked on the tests, they were failing, and can't remember why, so looks like the patch doesn't address all the problems...

@jsacksick i have this patch too https://www.drupal.org/project/drupal/issues/3300404 📌 Unserialize(): Passing null to parameter #1 ($data) of type string is deprecated in Drupal\Core\Entity\Sql\SqlContentEntityStorage Needs work

@tBKoT: Interesting approach, just wondering if this isn't a breaking change?
Also, we might as well copy what was done in Commerce API. The Commerce API module defines an Adjustment data type as well as an AdjustmentDataDefinition definition class.

The data definition class defines all the adjustment properties. This should help getting rid of the "value".

@jsacksick I've tried to get rid of the "value" key but it seems that it is not possible without rewriting a lot of staff or removing the denormalization process in the test (it would fail in this case)

The main thing is that JSON:API uses the field property definition as a foundation to generate the structure if we change it as a result all other things related to this field would be broken such as getAdjustments() etc. as those methods use "value" and I guess many other contrib/custom solutions may use this field like that.

Another thing that can help is to define more properties with their own data types to set values for Label, Type, Amount, etc. I do not think it is the best way to resolve this.

One more solution is to disable access to the main "adjustment" field for JSON:API as it is done in the "commerce_api" module and define a new computed field for it to show adjustment without the "value" key.