- last update
over 1 year ago 538 pass - ๐ฆ๐นAustria drunken monkey Vienna, Austria
Thanks for reporting this issue, and sorry it took me so long to get back to you.
I was able to reproduce the problem, but I donโt think its root cause is actually in this module. It seems something is wrong with entity queries on the Order entity type โ either a bug in Core or in Commerce.To be more precise, this is the query executed in your scenario:
\Drupal::entityQuery('node') ->accessCheck(FALSE) ->condition('billing_profile.entity', 1) ->execute()
It fails with โ'billing_profile' not foundโ, as you say.
However, this logically equivalent query works:
\Drupal::entityQuery('node') ->accessCheck(FALSE) ->condition('billing_profile', 1) ->execute()
Itโs not a very pretty solution, but I guess we can just change the query in the specific scenario to work again.
The problem, of course, is that this will still fail the same way as before when a sub-field is used as the filter โ e.g.,billing_profile.entity.given_name
. I therefore think we should, after applying this workaround to our module, move the issue to the Commerce issue queue. (Someone else recently created another issue regarding indexing of Order entities ( ๐ Indexing commerce orders via Drush triggers OrderRefresh Active ), so it seems there is just something very peculiar about that entity type.)But for now, please see the attached patch and tell me if it fixes the problem for you!