🇬🇧United Kingdom @guy_schneerson

will give it a test and commit

lol, we all do it.

Did you turn on the "Automatically return stock on cancel" in the "Core stock events" section of the stock config page /admin/commerce/config/stock/settings ?

guy_schneerson → created an issue.

Thanks @wxactly Patch works and makes sense. Committed

Thasnks @ELC

I believe this is fixed by https://www.drupal.org/project/commerce_stock/issues/3309574 📌 Field widget doesn't allow to set initial stock level if purchasable entity hasn't been created Needs review
Do reopen if it is still an issue.

I was not sure about the setting of the adjustment to zero in the postSave but after review and testing, I can not find a good reason not to.
Commit as is and thank you @Berdir for the work and @Lukas von Blarer
for testing

I committed a change to the info file requiring a version greater than 9.1. Anyone using 8 should use the patch above.

Stock does not currently use the AvailabilityManager and has its own system. It does however have an Empty (Always TRUE) implementation that would be good to implement and I'll be happy to look into it if it will solve this issue.

However, it looks to me like the auto-add does not trigger the AvailabilityManager->check() so I can't see anything we can do. @rszrama do you have an idea of how to approach this or can the Auto Add use the AvailabilityManager or some other method to hook in?

Thanks @apaderno
Yes, definitely needed this. I updated the page. If you find any issues please reopen and point out any suggestions.

Hi all and thanks for your attention to this.
The proposed change does not consider all the permutations of the Stock Level Widget. I assume you are all using the "Absolute stock level" and looks to me like the patch will make the use of the "Simple Stock transaction" even more confusing.
I personally discourage the use of the inline for use with stock, but if a good solution that works for all cases is proposed I will be happy to commit it.

Thanks for reporting. changing priority to Normal as this is not more important than other Bug reports.

Thanks, @DiDebru for the patch and @maxwellkeeble for testing.
Committed, but I am curious as it is in the code that runs for Cron run mode "Legucy/Full". the "Optimal". As far as I know, there are no issues with that mode and as its name suggests it's much more optimal.

@ELC, I am hoping to have a full release soon but meanwhile, if people are stuck on versions before 9.1 I would recommend changing the corn mode to "Optimal" admin/commerce/config/stock/local_stock_config
and if that does not solve the issue use the dev version. Hope that helps.

A patch updating the logic if refresh_once is true set to 1 otherwise use the corn configuration.

guy_schneerson → created an issue.

would be nice to get a stable release with D10 support.
not a big issue as can use the dev or the patch.

Updated patch.
Many of the changes made it into the module. This patch includes the remaining change.
I am not sure I fully understand why the original code created the $three_d_payment_method and not used it so hoping this will solve my issue.
Also storing the $payment_method against the order and restoring it does not feel like the best way to do this but if it works so be it.

<?php
-    $this->order->set('payment_method', $payment_method);
+
+    $this->order->set('payment_method', $three_d_payment_method);
+    // We will need to change the payment method back after payment so that
+    // recurring orders or failed payments won't use the nonce.
+    $this->order->setData('payment_method_reusable', $payment_method->id());
?>

and

<?php
       $transaction_data['paymentMethodNonce'] = $payment_method->getRemoteId();
+      $order = $payment->getOrder();
+      $reusable_payment_method_id = $order->getData('payment_method_reusable');
+      if ($reusable_payment_method_id) {
+        $order->set('payment_method', $reusable_payment_method_id);
+        $order->save();
+      }
?>

guy_schneerson → created an issue.

Found what looks like a related issue https://www.drupal.org/project/commerce_shipping/issues/3391283 ✨ The "Display taxes of this type inclusive in product prices" is used for more than just display Active

guy_schneerson → created an issue. See original summary → .

Incomplete/invalid patch.
I am not sure if this is a bug. I am not aware of the __tostring() magic method being a requirement and happy to change it back to bug if I am wrong.
In any case, I am happy to implement a __tostring() but will need a valid patch and it should return the ID and Label.
Thanks, @justsomeguy.com for bringing this up

Thanks @Mohamed Nabawy for the patch and @RandalV for testing.

guy_schneerson → created an issue.

Tested with:

The merge request !12 by @simgui8 works and is essential for working with the latest version of commerce CommerceCartEventSubscriber and should ideally be committed for supporting a smother Drupal 10 upgrade path.

For anyone needing to get their site ready beforehand, you can add it as a patch to your composer.json

        "patches": {
            "drupal/commerce_cart_flyout": {
                "after upgrading to Commerce Core 8.x-2.36 this module doesn't work": "https://git.drupalcode.org/project/commerce_cart_flyout/-/merge_requests/12.patch"
        }
            }

A big thank you to everyone that helped with this. I just pushed 8.x-1.1 and marked the issue as fixed. If anyone gets any issues specific to D10 then please reopen.

@agoradesign should be good to go. Dev version should be all fine if you can give that a go and confirm that will help.
I am away until Thursday and can push a version then.

After testing on both 9 and 10 I committed SilviuChingaru patch commerce-stock-d10-compat-3330022-8.patch
I assume we will still fail tests and we will need a second commit but thought it best to have a dev version with 10 support to work and test on.
Will look at the other proposed changes wen I can.

@NicklasMF thank you for your hard work on this.
I Tested on 10.0.3 with commerce 2.33 and all worked so far.
I have not had a chance to test with 9 and I can see how Symfony 6 events may be an issue although it looks like Symfony 5 has an Event class that provides a forward-compatibility layer so maybe it will just work.

Thanks, @silviuchingaru I was expecting the Event stuff and could not think of anything else that should cause an issue so I suspect you got it spot on :)

The patch did not work for me as is. Looks like I have a similar issue as that of #29. The existence of the aggregations _global data courses the main if condition to be skipped and the count, as a result, is wrong. Removing that part of the condition causes that block to run every time and the counts look correct.
I am using a locally modified patch but I assume it is not the correct solution, I just don't have enough understanding of the issue to figure it out.