[UPD] account_payment_adyen_refund: compute payment reference

[ntsirintanis]

@NL66278 please take a look

[NL66278]

Or simpler:

 def _compute_reference(self): 
        """Adjust reference to avoid uniqueness constraint"""
        existing_count = self.env["payment.transaction"].search_count([("reference", "=", reference)])
        if not existing_count:
            return reference
        return reference + "-" + str(existing_count)

[ntsirintanis]

Yes, here existing_count is doomed to be 1 or 0, forever, since the reference constraint exists. So if we have a reference A, next one by this method will be A-1. If we try to create another reference from A, it will still return A-1, triggering the constraint. So I restored this to its previous version

[NL66278]

I do not quite see this. The first 0 existing, so reference will be A. Next one will find 1 existing, so reference will be A1, one after that will find 2 existing, so reference will be A2 etc.

[NL66278]

Aha I see the problem, the '=' in the search should be changed into a like as well...

[NL66278]

To be exact: [("reference", "=like", reference + "%")]) to only search on reference that have the same starting characters.

[ntsirintanis]

@NL66278 we tested this too; if sending to adyen fails, the refund_status remains on send

[NL66278]

I have some doubts about this. Not on the need for a commit, but maybe it should be in a separate cursor, dedicated to updating the invoice.refund_status. In this way, all other changes will still be rolled back on failure. The update of the refund status could be part of a separate method (in the account.invoice model) like so:

from odoo import registry (add to existing imports from Odoo)
...
def _update_refund_status(self, status):
        self.ensure_one()
        self.flush()  # Not needed from 15.0 upwards
        with registry(self.env.cr.dbname).cursor() as cr:
            self.with_env(self.env(cr)).write({"refund_status":"refund_status})

See also this discussion: odoo/odoo#82928

[ntsirintanis]

So what you are proposing here:

• A payment will be created
• The invoice status will change to send
• The payment cannot be sent to adyen, because of some error during the sending process
• everything rolls back (including the payment creation) except the invoice status

Is this correct?

[NL66278]

@ntsirintanis Indeed I think it should work like that. Note that you might still need to disable the pylint check for not having commits (and check the other stuff in the pre-commit log, but those are minor things). Just to be sure check also with @lfreeke . When processing in batch (server action or cron in customer code) it should still be possible to commit each successfully completed transaction (and rollback the unsuccesfull ones) depending or not you want the cron to proceed with other transactions when one fails.