ts.ag → created an issue.
I am also seeing this error with REST export views for Commerce Log entities, if the view results contain any Log entity which has a template that expects Price parameters. Since a typical checkout flow implies an automatically-created payment after completion, the order's activity log will have an entry for the payment with its amount, and so you can't expose the activity log of non-draft orders.
Fixed patch from #5 due to of incorrect calls to $this.
Expanded previous patch to use the skip feature in the batch from CouponGenerateForm.
Attaching a simplistic patch which enables skipping the problematic operations inside both postSave()s if a batch is running and corresponding flags are set in its definition. Usage:
$batch_definition = [
'commerce_promotion__skip_ops' => TRUE,
'commerce_promotion_coupon__skip_ops' => TRUE,
...
];
batch_set($batch_definition);
ts.ag → created an issue.
For anoyone who might still reach this from search results:
Incorrectly configured paths (for example, from custom resources) also give an empty messages. For example, if the path "/custom_resource/{entity}" cannot receive an "entity" parameter (because, say, it expects a "custom_entity" one).
Although, in my opinion, this also falls within the scope of this issue since custom resources are by definition extending the core rest infrastructure, and so it should therefore be reopened (or a new one created).
The same type of issue is present on product variation types - you can only choose one order item type for each in their config, but they can be added to any order item type during the order creation process.
However, I agree with the concerns that limiting the default behaviour to a 1:1 relationship would only make sense for specific use-cases. A multiple select field should be the approach on this.
ts.ag → created an issue.
@gisle - Sorry about that, I could swear I didn't touch the metadata options, just typed a comment & clicked save.
I'm having a somewhat opposite issue with user role conditions - they get applied for any user roles, not just the chosen roles.
Even weirder, the rule's admin theme is not applied in the front area (for stuff like admin menus), which is correct behaviour, but in the admin area there is a blend of the default admin theme and the rule's admin theme. #imnotevenmadthatsamazing
Attached an example of the default Gin theme and the rule's Adminimal theme.
Thank you @vishal.kadam & @gisle !
ts.ag → created an issue.