Hi @bceyssens, I have added my changes to an issue fork branch.
I would like to get the tax in a more dynamic way: from order/orderLineItem adjustments (or possibly shipment or invoice adjustments). I also see a scenario with different tax amounts, so instead of calculating it in UblBuilder::getBlob() we should probably take the inclusiveAmount and exclusiveAmount and taxAmount from the invoice.
That way you use whatever method was used to arrive at the tax stated on the invoice.
I have made a first patch that takes the percentage from the first orderItem Adjustment of the tax type. Far from perfect, but it's a start. I can add it to this issue if people are interested.
Stuff to figure out:
- Use multiple busses
- Use multiple queues
- Disable cron queue handling of the messenger queue
- Make sure the worker is limited by time/number of items/memory/etc
- Make sure the worker is restarted: or leave this to supervisord (see SF messenger docs)
- Add the \Symfony\Component\Messenger\RoutableMessageBus as a service so we can use that
- Add various Symfony classes as services so we can use them: receiverLocator, busLocator, rateLimiterLocator
I made a first draft for async handling.
1) copied \Symfony\Component\Messenger\Command\ConsumeMessagesCommand to \Drupal\symfony_messenger\Command\ConsumeDrupalMessagesCommand
Modified the command to be Drupal compatible. Most checks and options need to be re-enabled.
2) copied core/scripts/drupal to symfony_messenger/scripts/drupal-cli
Modified the script to load the ConsumeDrupalMessagesCommand. Added the kernel boot function from \Drupal\Core\Command\ServerCommand::boot.
3) modified \Drupal\symfony_messenger\Transport\DrupalTransport and other files to make it all work:
- if you now run the controller at /symfony-messenger-example an ExampleRequest message is send to the DrupalTransport bus.
- The DrupalTransport bus saves the message as a Drupal Queue item.
- you can start the worker similar to how the Symfony Worker is started (see https://symfony.com/doc/current/messenger.html#consuming-messages-running-the-worker), for Drupal this would be > ./web/modules/contrib/symfony_messenger/scripts/drupal-cli consume-messages
- If the worker is started or the worker is running queue items are picked up and handled by ExampleRequestHandler.
Review: patch looks good.
This makes the behaviour identical to other views dialogs such as sort. The misalignment can be addressed in the followup.
hide patch files, using merge request
I did a reroll of the patch for 11.x. It should be in the merge request.
finne → made their first commit to this issue’s fork.
Looking at how Symfony achieves asynchronous message handling:
To consume messages using a separate PHP process, making it truely asynchronous, you need to run a CLI command on your production server:
php /path/to/your/app/bin/console messenger:consume async
This command is kept alive, restarted and quit by a linux service suchs as supervisord.
To achieve a similar thing in Drupal I think we should use drush. Drupal Console seems to be used much less.
So a similiar setup would be to have supervisord run
php /path/to/your/app/vendor/bin/drush messenger:consume async
Then we should translate Symfony Console commands to drush commands. Especially messenger/Command/ConsumeMessagesCommand.php
Thanks rhovland, I had the same problem: we are deleting shipments using a custom action in the GUI. Since this commit the shipment's profiles are also deleted: in our case we linked the order billing profile. So that was gone too.
We should probably rework the usage of profiles, but the patch is very welcome in the meantime.