[#68095] Fix payment method labeling in data migration

[peregrine-2024]

: This pull request addresses ticket #68095 where payment transactions were being migrated with generic 'Payment method' labels instead of specific methods like Sofort, iDEAL, or Card. The fix enhances the migration script to properly map payment methods from sale orders to payment transactions by utilizing the sale_order_payment_method_id field during the migration process. This ensures accurate payment method representation in the migrated data.

[peregrine-2024]

🛠️ Automated Fix: Payment Method on Payment Transactions Now Uses Specific Values

This pull request addresses Ticket #68095 titled "Bug: Payment Method on Payment Transactions Not Fully Setup".

✅ What Was Actually Implemented

The core issue was that payment transactions were being created with a generic "Payment method" label instead of specific payment methods such as Sofort, iDEAL, or Card. This PR introduces a new Odoo module (osi_payment_transaction_method) to correctly map and assign payment methods from related sale orders to payment transactions.

---

🔧 Key Changes Overview

1. New Module: osi_payment_transaction_method

A new Odoo module was added to handle the correct assignment of payment methods to payment transactions.

2. Core Logic in payment_transaction.py

• Inherited payment.transaction model to override creation and write behavior.
• Added _set_payment_method_from_sale_order() method to fetch and apply the correct payment method from associated sale orders.
• Added fallback logic to extract payment method from either:
  • sale_order_payment_method_id field (if present), or
  • Directly from the sale order’s payment method lines.
• Includes checks to avoid overwriting already-set non-generic payment methods.

3. Post-Init Hook Support

• Introduced a post_init_hook to initialize data migration logic for existing records.
• The hook is registered via manifest and executed during module installation.

4. Views Updated

• Modified XML view definitions (payment_transaction_views.xml) to ensure proper UI handling of the updated payment method field.

5. Manifest File

• Defined dependencies on payment and sale.
• Registered the post-initialization hook.
• Included view updates and set module as installable.

---

📌 Technical Highlights

File	Description
models/payment_transaction.py	Main logic for setting payment method from sale orders; overrides create() and write() methods.
models/payment_transaction_post_init_hook.py	Contains logic to process existing payment transactions during module initialization.
views/payment_transaction_views.xml	Ensures UI reflects the correct payment method display.
__manifest__.py	Declares dependencies, views, and hooks required for functionality.

---

🧪 Testing & Review Notes

• Ensure that existing payment transactions are properly updated with correct payment method values upon module activation.
• Test with various sale order configurations including those using sale_order_payment_method_id and standard payment method lines.
• Verify that no regressions occur in existing payment flows.

Please review the code changes carefully, especially around the logic in _get_payment_method_from_sale_order_method() which handles complex relationships between sale order payment methods and their underlying payment method references.

🔗 View Ticket #68095 for more context.