ConditionBase should provide a way to access the target entity the condition applies to

Confirming that. There seems to be no way to get the host entity of the condition that's being evaluated, but that might be needed to get details, like in our case. Currently, only seems solvable through our hacky workaround.

Once the maintainers tell which way to go, we can of course provide a MR to implement that. Simply shouldn't waste time.

I've been rereading this multiple times, and not 100% sure what you're asking here.
Which target entity are you trying to target? The shipment? The shipping method?

fwiw, you can also attach the condition to the shipment.

*edited*

@jsacksick thanks for your quick reply. I know this is not easy to understand, if you don't run into it.

I'll give it a try in my own words:

In a condition's evaluate() call, in our case a shipping method, there seems to be no way to get the entity ("context") which uses this condition.

In this case, Shipping method S has a condition C enabled. Within the condition C you need to get further information from S e.g. in our case simply the ID.

Conditions are general and can be re-used in different places, so C (and others) for example have
entity_type = "commerce_order", but are used within Shipping methods. So the relation happens at runtime and the entity_type passed as parameter to evaluate() is not the context. The shipping method is the runtime context.

Maybe it helps to imagine a similar case for Drupal core conditions and blocks.
A block uses a "path" condition. The path condition's code can't know in which entities it's used, not even if it's a block or a settings page or any other entity. But at runtime there's no way to get the host entity in the condition, but there are cases where you need it.

I guess while this specific use-case is in Commerce, the general runtime logic, where the caller needs to identify himself to the evaluate-method, is a core issue.

Is this clearer?

I think what you're looking for is the ParentEntityAwareTrait + its interface.

See https://git.drupalcode.org/project/commerce/-/blob/3.0.x/modules/promoti....

Let me know if this doesn't help.

Thanks @jsacksick! @grevil please look at https://docs.drupalcommerce.org/v2/developer-guide/core/conditions/#prov... and see if that solves our problem.

Yea that is exactly what I was looking for, thank you, @jsacksick!

@jsacksick what is the reason, that the parent entity (aka the condition target) isn't exposed by default? I mean the condition doesn't have to use it and executing "$condition->setParentEntity($this)" for each condition shouldn't hinder performance too much right? (Generally curious not saying it's a bad choice).

The reason is simple, this was introduced after the fact, so calling this method by default would break if the condition plugin didn't implement it.

But all conditions extend ConditionBase? Meaning, if it got introduced in ConditionBase, it would always be implemented?

Of course, then every parent class needs to call "$condition->setParentEntity($this);" and we would have a breaking change / an unintended behavior for entities that don't, so yea kind of understandable, thanks for the info!

Automatically closed - issue fixed for 2 weeks with no activity.