Regarding comment #10, I had the same issue when handling order items for which the price was not calculated yet, so I created issue #3489811 🐛 AddToCartEvent WSOD for order items with no price Active
ts.ag → created an issue.
Patches from #5 & #6 were missing self:: for constant calls.
Patch from #5 contained an unused argument in the settings service.
Added cache for the user data because for websites with thousands of users there was a significant performance drop due to the large number of DB requests.
Added a hidden_permissions form element with an array value for all hidden permission values, and extended submitForm() to merge these with the submitted values and save all permissions.
Also updated issue summary.
I'm not sure an update hook is needed, it might in fact muddy waters depending on use cases.
Something to keep an eye on: there's work being done for Drupal core 11.x to address the general issue of saving overridden config entities - https://www.drupal.org/project/drupal/issues/2910353 🐛 Prevent saving config entities when configuration overrides are applied Needs work
Patch from #2 doesn't work if the overridden permissions are hidden from display based on the chosen filters, the config still gets polluted with the hidden overriden values on save.
Will have to dig deeper, I'll probably take another whack at it this week.
ts.ag → created an issue.
Added user data override for config, now there's an "override for me" option besides the global setting.
Fixed missing CommerceSettings param in ProductVariationTypeForm constructor.
ts.ag → created an issue.
ts.ag → created an issue.
ts.ag → created an issue.
We had this issue after a drupal/rat update that introduced a git repo inside its directory that was rejected downstream (eg. Pantheon), so the vendor/drupal/rat directory remained empty downstream due to no changes being detected in composer.json on subsequent pushes.
We resolved it by removing and re-adding the directory to git:
git rm --cached vendor/drupal/rat
git add vendor/drupal/rat
git commit ...
git push ...
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.