Triggering escrow via Rules leads to WSOD in drupal 10

Hmm, they were a lot of changes made to the rules module since then.

Could you try on a fresh installation? Also, maybe just try to rebuild your rule.

Personally, on a fresh Drupal 10.2 install, I don't even get the transaction to be created when saving content. I don't think it comes from commerce_funds but from the rules module.

Also, now commerce_funds provide fields that you can add to your content type, maybe you can find a way to do what you want without using rules.

Thanks a lot Aporie for your extra fast reply.

I tried on a fresh D10.2 installation and had the exact same issue.

Trying to rebuild the rule also doesnt work. In Rules, the transaction action is done in two steps:
1- Add action "Create a new transaction entity" --> This works as before
2- Add action "Perform transaction" --> This is not possible anymore, when this action is selected in the available actions list (in Rules UI), there is an immediate WSOD.
If on your side you could not create the transaction, maybe it was because you missed step 2? Or didn't you experience this WSOD when selecting the "Perform transaction" action as I do?

To note that the only thing that has changed in my setup is the upgrade Drupal 9.5-->Drupal 10.2 (my Rules and CF modules were already at their latest version far before doing this upgrade and everything worked perfectly at that time). Also I did not have any issues appeared with my other rules. This leads me to think that the problem is probably linked to the RulesAction plugin of commerce_funds, which should somehow adapt something to work on D10?

I was not aware about the transaction fields that have been added, so thanks for the info. However and unless I missed something I could only find a field for doing transfers. My use case only uses escrow payments (which is a transaction offered by the commerce_funds module), as I need to have money exchanges between users retained between two workflow points: User A requests something to user B and initiates an escrow (the money is withdrawn from his account), then User B does what user A has requested, and only after User A confirms the User B achieved the requested task the money is credited on User B account (escrow finalzed). Is there a way using this transaction fields to retain a payment in the way described above (meaning to have a kind of escrow field)?

Thanks again

Hey,

Yeah I might have forgotten to put the perform transaction action. I think I've written a how to somewhere on my website, I'll try again when I have a bit of time.

Regarding the field you should be able to change the transaction type in the form field formatter if I recall correctly ...

Ok, had some time to look into it.

The attached patch should fix the WSOD error. TBH, I don't even know how it used to work before.

Though, I tried to make it work with a rule and still not successful.

I had two issues:

1. I can't use a "Commerce Price" field in my content using node.field_amount.number and node.field_amount.currency as now rules validation returns an error expecting a decimal number and not a string.
2. When saving my content type where the rule should apply, nothing happens. Even when I add two extra actions, save entity and perform transaction. But now I can't select entity in data selector, I can only select commerce_funds_transaction_created (which is probably something rule created itself).

I found the How to again.

Thanks a lot, the patch works like a charm and solves the issue.
May this help regarding your two points:
1. Indeed, Rules UI will not accept a price field (number) as it requires a decimal input. Two workarounds: Either to import a rule configuration with the node.field_amount.number in the YAML code (this will bypass the data type check and the rule will work perfectly) or convert the price field into a decimal value (rules offers data conversion actions).
For the currency, I do not have any trouble, I simply enter the currency code string (e.g "EUR") into the currency field and it works. Take care to enter it in "direct input mode", and not "data selection mode"

2. What you should do is:
a- Add an action "Create a transaction entity" and fill in the necessary fields: type, issuer, recipient, brut amount, currency, payment method, currency and status. In my case, I assign as well a hash (equal to my node uuid) and I leave net amount and fees fields blank (automatically calculated using the commerce_funds modules settings).
b- Add an action "Save entity", select commerce_funds_transaction_created (or the rules variable name you have assigned if you modified it at the step before), and put 1 in "Force saving immediately"
c- Add an action "Perform transaction" by selecting "commerce_funds_transaction_created" (or your rules variable name if you modified it at step a) in the data selector.
With this it should normally work (the transaction should be visible in the commerce_funds view showing all site transactions and user balances are updated accordingly.
If following these steps does not work for you, do not hesitate to share screenshots or additionnal info so that I can support you finding what goes wrong (I know that the Rules interface is a bit picky). Combining commerce_funds with Rules is really powerful and this interface should be kept in my opinion.

Regarding the transaction fields this is definitely a great feature covering most probably a large number of use cases, but unfortunately not mine. Indeed, Rules will not allow any action on this field, as at the time the Rule is triggered the entity referenced by the field is not created (I have spent my day testing it with all possible twists I know, but without success).

Hoping it helps you as well in return!
Thanks again

Hi Arno2Mars,

Thanks a lot for your detailed explanation. I finally got it working!

Also needed to set the status of my transaction to "canceled". I've updated my article on my website and allowed myself to comment your trick to bypass rules validation checks on price fields.

Automatically closed - issue fixed for 2 weeks with no activity.