SearchFilter shouldn't rely on nested resources having an "id" field

[mrossard]

API Platform version(s) affected: 3.1.12

Description
When you use a SearchFilter on a nested property that is a resource and doesn't use "id" as its identifier you get "Can't get a way to read the property "id" in class XXX".

How to reproduce
Have 2 resources A and B, with A containing a B (both simple ApiResources using entityClass=... in my case)
Use an ApiIdentifier in B that is not "id", ie IRIs are /Bs/{someotherfield}.
Add a searchfilter for the B member on A :

#[ApiFilter(SearchFilter::class, properties:['b'])

Possible Solution
Didn't have time to dig into this yet, but it's happening in SearchFilterTrait line 127 :

return $this->getPropertyAccessor()->getValue($item, 'id');

This should probably be replaced so it at least looks for id in the entityClass when present, or even tries to get the ORM to return the correct id(s) without hard coding it.

[j-schumann]

Similar issue here w/ same version. Only difference: Problem occurs when the resourceClass has an identifier not named "id", but the association's identifier is indeed "id", as Doctrine\Orm\Filter\SearchFilter#L126 re-uses the resource's identifier name(s).

#5623 in its current state would fix this.

[mrossard]

There are indeed 2 issues here - the hardcoded "id", and then the main resource metada being reused instead of the association's. I'll try to get my fix up to standards so it gets merged.