Payment log entries are not being saved for refunds

[kennyadsl]

Apparently, refunding a payment is not creating a payment log entry when executed.

☝️ In this example, the order has been cancelled, and a payment have been automatically refunded with the credit method on the payment method/gateway. This is not attaching the log entry event to the payment.

As you can see, the refund that is correctly created for the order, is linked to the original payment, so there's no apparent reason not to link the credit log entry event to the payment:

Solidus Version:
All

To Reproduce

First of all bundle exec rake sandbox and bin/rails s

1. Complete a payment on the frontend
2. Go to admin, capture the payment of the newly created order
3. Refund the payment.
4. No log entry event for the refund.

Current behavior

No log entry event logged on the original payment for its refund.

Expected behavior

A log entry event logged on the original payment for its refund.

Screenshots

See above.

[senemsoy]

@benjaminwil and I are working on this.

[kennyadsl]

Hello @senemsoy! Are you still working on this? I think we are facing this in the Stripe extension, and if you and @benjaminwil did find anything worth sharing, it would be great to know. 🙂

[benjaminwil]

@kennyadsl We were able to reproduce the issue but haven't had time to find the source. We just created a pull request with a pending feature test so someone else can pick this up if it's urgent. 👍

[cesartalves]

It seems that the LogEntrie(s) are built, but never saved when performing the refund. See

solidus/core/app/models/spree/refund.rb

Line 56 in b08aa4f

log_entries.build(parsed_payment_response_details_with_fallback: perform_response)

[rainerdema]

After a recent team conversation, we have decided to postpone addressing this issue until the implementation of the new admin, which is already underway.

The main reason for this decision is that the logs are being saved correctly with the related Spree::Refund source, but the current view only displays logs originating from Spree::Payment source type.

In conclusion, the issue is primarily related to view presentation rather than data integrity.

The overhaul of the admin interface will provide an opportune time to enhance the view presentation of these logs, ensuring a more comprehensive and accurate representation and including details about the log origin.

cc @solidusio/core-team