@tonytheferg

I'm supportive. Glad to review a well written merge request.

Thanks for posting the issue.

I am finding I can't reference unpublished nodes through the autocomplete form, even as admin with all permissions

Maybe add an option to have it at the top and the bottom?

For sites with a longer list of suggestions, someone might scroll past the link at the top in hopes to see if what they're looking for is in the suggestions, only to go through the list and not see what they are looking for. They would then would have to scroll all the way back up to get to the see all results link.

Looks like it's off to a good start! Thanks!

I think a case can be made where you don't want deleting the parent on an admin order to delete the children.

So the only thing I think is needed here is to decide what the behavior should be with orders created programmatically. I know I encounter bumps with this patch when migrating, but I had a specific use case were variations were becoming parents in the migration.

We could check for the Order admin form in the request if we wanted to restrict this to admin UI orders.
We could also offer a setting. But I think those could be addressed down the road.

This bit was necessary for making sure the parent wasn't deleted:

    // Ensure that order items are not compared with themselves.
    $order_items = array_filter($order_items, function ($existing_order_item) use ($order_item) {
      return $order_item->id() !== $existing_order_item->id();
    });

Ok, moved child creation to a service instead of having it jammed in the event subscriber. The only bit that really deals with this issue is the section from the presave event:

      // Create children for non-cart orders only.
      if ($order->hasField('cart') && !$order->get('cart')->value) {
        $product_variation = $order_item->getPurchasedEntity();
        if (!$product_variation) {
          continue;
        }
        $children = $this->vadoChildManager->createChildren($order, $order_item, $product_variation);
        return $children;
      }

Needs work for pipelines/tests.

Saw this in the log, dropping the stack trace here:

Drupal\commerce_order\Exception\OrderVersionMismatchException: Attempted to save order 20231 with version 6. Current version is 7. in /code/web/modules/contrib/commerce/modules/order/src/Entity/Order.php:719
Stack trace:
#0 /code/web/core/lib/Drupal/Core/Entity/EntityStorageBase.php(528): Drupal\commerce_order\Entity\Order->preSave(Object(Drupal\commerce_order\OrderStorage))
#1 /code/web/core/lib/Drupal/Core/Entity/ContentEntityStorageBase.php(753): Drupal\Core\Entity\EntityStorageBase->doPreSave(Object(Drupal\commerce_order\Entity\Order))
#2 /code/web/core/lib/Drupal/Core/Entity/EntityStorageBase.php(483): Drupal\Core\Entity\ContentEntityStorageBase->doPreSave(Object(Drupal\commerce_order\Entity\Order))
#3 /code/web/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php(806): Drupal\Core\Entity\EntityStorageBase->save(Object(Drupal\commerce_order\Entity\Order))
#4 /code/web/modules/contrib/commerce/modules/order/src/OrderStorage.php(169): Drupal\Core\Entity\Sql\SqlContentEntityStorage->save(Object(Drupal\commerce_order\Entity\Order))
#5 /code/web/core/lib/Drupal/Core/Entity/EntityBase.php(354): Drupal\commerce_order\OrderStorage->save(Object(Drupal\commerce_order\Entity\Order))
#6 /code/web/modules/contrib/commerce/modules/checkout/src/Plugin/Commerce/CheckoutFlow/CheckoutFlowBase.php(463): Drupal\Core\Entity\EntityBase->save()
#7 /code/web/modules/contrib/commerce/modules/checkout/src/Plugin/Commerce/CheckoutFlow/CheckoutFlowWithPanesBase.php(614): Drupal\commerce_checkout\Plugin\Commerce\CheckoutFlow\CheckoutFlowBase->submitForm(Array, Object(Drupal\Core\Form\FormState))
#8 [internal function]: Drupal\commerce_checkout\Plugin\Commerce\CheckoutFlow\CheckoutFlowWithPanesBase->submitForm(Array, Object(Drupal\Core\Form\FormState))
#9 /code/web/core/lib/Drupal/Core/Form/FormSubmitter.php(129): call_user_func_array(Array, Array)
#10 /code/web/core/lib/Drupal/Core/Form/FormSubmitter.php(67): Drupal\Core\Form\FormSubmitter->executeSubmitHandlers(Array, Object(Drupal\Core\Form\FormState))
#11 /code/web/core/lib/Drupal/Core/Form/FormBuilder.php(597): Drupal\Core\Form\FormSubmitter->doSubmitForm(Array, Object(Drupal\Core\Form\FormState))
#12 /code/web/core/lib/Drupal/Core/Form/FormBuilder.php(326): Drupal\Core\Form\FormBuilder->processForm('commerce_checko...', Array, Object(Drupal\Core\Form\FormState))
#13 /code/web/core/lib/Drupal/Core/Form/FormBuilder.php(224): Drupal\Core\Form\FormBuilder->buildForm(Object(Drupal\commerce_checkout\Plugin\Commerce\CheckoutFlow\MultistepDefault), Object(Drupal\Core\Form\FormState))
#14 /code/web/modules/contrib/commerce/modules/checkout/src/Controller/CheckoutController.php(143): Drupal\Core\Form\FormBuilder->getForm(Object(Drupal\commerce_checkout\Plugin\Commerce\CheckoutFlow\MultistepDefault), 'login')
#15 [internal function]: Drupal\commerce_checkout\Controller\CheckoutController->formPage(Object(Drupal\Core\Routing\RouteMatch))
#16 /code/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(123): call_user_func_array(Array, Array)
#17 /code/web/core/lib/Drupal/Core/Render/Renderer.php(638): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
#18 /code/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(121): Drupal\Core\Render\Renderer->executeInRenderContext(Object(Drupal\Core\Render\RenderContext), Object(Closure))
#19 /code/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(97): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array)
#20 /code/vendor/symfony/http-kernel/HttpKernel.php(181): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
#21 /code/vendor/symfony/http-kernel/HttpKernel.php(76): Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object(Symfony\Component\HttpFoundation\Request), 1)
#22 /code/web/core/lib/Drupal/Core/StackMiddleware/Session.php(53): Symfony\Component\HttpKernel\HttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#23 /code/web/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(48): Drupal\Core\StackMiddleware\Session->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#24 /code/web/core/lib/Drupal/Core/StackMiddleware/ContentLength.php(28): Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#25 /code/web/core/modules/big_pipe/src/StackMiddleware/ContentLength.php(32): Drupal\Core\StackMiddleware\ContentLength->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#26 /code/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(116): Drupal\big_pipe\StackMiddleware\ContentLength->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#27 /code/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(90): Drupal\page_cache\StackMiddleware\PageCache->pass(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#28 /code/web/core/modules/ban/src/BanMiddleware.php(50): Drupal\page_cache\StackMiddleware\PageCache->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#29 /code/web/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(48): Drupal\ban\BanMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#30 /code/web/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(51): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#31 /code/web/core/lib/Drupal/Core/StackMiddleware/AjaxPageState.php(36): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#32 /code/web/core/lib/Drupal/Core/StackMiddleware/StackedHttpKernel.php(51): Drupal\Core\StackMiddleware\AjaxPageState->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#33 /code/web/core/lib/Drupal/Core/DrupalKernel.php(741): Drupal\Core\StackMiddleware\StackedHttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#34 /code/web/index.php(19): Drupal\Core\DrupalKernel->handle(Object(Symfony\Component\HttpFoundation\Request))
#35 {main}

Seeing this as well
Stripe\Exception\InvalidRequestException: The provided PaymentMethod was previously used with a PaymentIntent without Customer attachment, shared with a connected account without Customer attachment, or was detached from a Customer. It may not be used again. To use a PaymentMethod multiple times, you must attach it to a Customer first. in Stripe\Exception\ApiErrorException::factory() (line 38 of /code/vendor/stripe/stripe-php/lib/Exception/ApiErrorException.php).

New customer who has never checked out on our site to my knowledge.

+1 for this. When saving a custom admin only permission, the module was deleting all the other permissions in user.role.administrator.yml, and replacing with only the permissions for the field in question.

Thanks for the patch, it seems to fix the issue.

Thanks! Done. ✨ Add a "view all results" link setting for the autocomplete dropdown Active

tonytheferg → created an issue.

This applied to both Commerce 2 and 3, and there were no errors in the log when using the cart message.
+1 for RTBC
@loze, please apply the MR to 1.0.x-dev, and let me know how it goes.

Thanks @jsacksick!

This broke stuff. 🐛 Errors in the EventSubscriber when adding to cart Active

Yeah, this only happens against commerce 3.o.x-dev

Maybe revert the changes here and see what happens:
https://git.drupalcode.org/project/commerce_ajax_atc/-/merge_requests/7/...

For commerce are you on dev, or the last release?

Yes, that change is merged into the latest dev. OK, I will have a look. Thank you.

Please let me know what version of this module you are on, and what if any patches are applied. I also need to know what your ajax settings are as well. Clear steps to reproduce please.

Thanks!

Probably need to add the reference to the messenger before the request stack

Did you apply the fix I mentioned in the other issue?

Hi, can you please try the fix in this issue, clear the cache, and report back?

📌 AjaxCartEventSubscriber::$entityTypeManager declaration is redundant / problematic Active

This might prove tricky. If we create the order on submit, we would need to delete orders when the pop up is closed.
So we can grab the purchased entity and quantity on submit, and only create the order on pop up submission confirmation.

Otherwise you would have a draft order for every time someone pressed the button. A little more hacky boilerplate incoming.

Here is a start, just for fun. This could certainly and will need to be better written, but this does create a draft order for one order item, and respects the add to cart form quantity.

We would still would need to open a popup confirmation that:

• displays the order total and summary,
• confirms/checks the address(es),
• confirms/checks payment method,
• Submits the order,
• And redirects to a checkout completion page.

Might be good to put in a sub module within this module.

tonytheferg → created an issue.

Jumping in with a ping so that this might float to the top. I think the default setup should be to choose what entities you want to log.

I agree, certainly log history for deleted entities should be deleted.

Yeah, seeing this on any unpublished nodes. I agree this is bad to have this be an exception warning. Maybe info, or notice when it's because of an unpublished entity.

Also, It would probably be good to add ->setDisplayConfigurable('view', TRUE); to the base field to allow users to display this as it's good data to be able to display on the shipment.

tonytheferg → created an issue. See original summary → .

tonytheferg → created an issue.

I think we should start with a shipped timestamp which is set on send transition.

The changed timestamp should be kept distinct from the shipped timestamp, as you may make edits to the shipment before you send it.

I also think it would be good to add a delivered timestamp which is set on a new deliver transition.

Then websites that use carrier webhooks or paying for updates can set delivered timestamps accordingly in their own code.

I think the original issue would better be handled by trying to support the major carriers in callbacks to get those times dynamically.

Thanks!

Thanks! Is there any concerns with backwards compatibility here?
I am assuming this change won't work on commerce 2.x?

Yeah I keep all the pipelines current tests should run something broke. If you go to the repository and check pipelines you'll see that our last commit on dev all the pipelines passed so it's the change.

Thanks. NW as this broke tests.

Thanks!
On an unrelated note, has anyone requested a "view all results" link setting for UI? As some might not think to submit the form to land on the search page.

If this works for old sites, it should probably be tagged as 1.1.0-alpha5 or something like that so that it won't try to jump to it automatically.

tonytheferg → created an issue.

Please use Beta1 → . Thanks!

I think the best solution is to create a new 2.0.x branch and change the core requirement to ^10.3 || ^11.0, then create a new release (1.0.1-alpha5) with deprecations and version constraints rolled back to ^9.3 || ^10.

This is now fixed with 🐛 Group items should be hidden when variation is unpublished Active

Sweet. We now have test coverage for unpublished variations and deleted variations both as child add-ons and also in group items.

Moved product, variation, and group creation into an new VadoBrowserTestBase file so that we don't need to keep creating and recreating all the above. Also moved display creation to that file as well.

Should make tests a little easier and more performant moving forward.

Cool, all green I feel better about this.
Maybe a couple more tests to go with it.

Pulled the check for the variation entity out of the function to make the function better defined, and make the checks more explicit in the code base.
Function:

  /**
   * {@inheritdoc}
   */
  public function allowsUnpublishedVariation() {
    // If the setting is off, and the variation is not published, return FALSE.
    $allow_unpublished = \Drupal::config('commerce_vado.settings')->get('allow_unpublished_variations');
    if (!$allow_unpublished && !$this->getVariation()->isPublished()) {
      return FALSE;
    }
    return TRUE;
  }

Now you will see the checks like this:

      // If the group item doesn't have a variation entity, or if
      // the group item doesn't allow an unpublished variation, continue.
      if (!$group_item->getVariation() || !$group_item->allowsUnpublishedVariation()) {
        continue;
      }

Invalidating the cache tags on the $parent_variation at the beginning of the calculateBundlePrice function in VadoOrderProcessor seems to help:

  /**
   * Calculates the bundle price for the calculated price formatter.
   *
   * @param \Drupal\commerce_order\Entity\OrderItemInterface $order_item
   *   The order item.
   */
  protected function calculateBundlePrice(OrderItemInterface $order_item) {
    $parent_variation = $order_item->getPurchasedEntity();
    if (!$parent_variation) {
      return;
    }
    Cache::invalidateTags($parent_variation->getCacheTags());

Then when loading a new page you see the change, but not on refreshing the same page.

tonytheferg → created an issue.

I mentioned the pricing being cached when variations are deleted, or unpublished, but this is actually the case when prices on individual variations are changed as well. The order processor that calculates the price caches the price. This is a separate issue.

Need to cover child variations and write a couple tests as well.

So the entity reference view bit is easily handled by adding a relationship to the variation and making it required, and then adding a filter for published variations.

The only thing I notice so far is that after unpublishing or deleting a variation, the price on the add to cart form is cached.

Also not sure how to handle an unpublished product.
This all seems like smart stuff to add though. :)

Postponing as the fix on 🐛 Group items should be hidden when variation is unpublished Active might be a better approach. After that issue lands we can discuss whether or not to delete empty group items etc.

This is pretty close except for the views entity reference stuff. If we can work this out, this would address 🐛 Error: Call to a member function getCacheTags() on null in Drupal\commerce_vado\Entity\VadoGroup->getCacheTagsToInvalidate() (line 275 Active as well.

Sorry didn't see this comment. Yeah, the proposal is to delete group items WHEN the variation is deleted. You would have to query for groupt items that have no variation to find rogue group items.

It's not clear what you are trying to accomplish here. If you would please write a test only patch that shows the problem.

The Variation group view, and the Vado group add to cart form mode labels will probably just have to be fixed manually on existing sites.

tonytheferg → created an issue.

tonytheferg → changed the visibility of the branch 2.0.x to active.

tonytheferg → changed the visibility of the branch 2.0.x to active.

tonytheferg → changed the visibility of the branch 2.0.x to hidden.

This seems pretty straight forward, as it is a new entity, it shouldn't have an old date.

tonytheferg → created an issue.

tonytheferg → created an issue.

tonytheferg → created an issue.

Users can pin 2.0.0-rc5 for the time being if they are not on Drupal Core 10.3 or higher.