fix(payment gateway account): remove payment gateway field

[diptanilsaha]

Removed the payment_gateway field from the Payment Gateway Account DocType. Added a patch to add the payment_gateway custom field if the payments app is already installed.

Closes: #45220
Ref: frappe/payments#185

[coderabbitai]

📝 Walkthrough

Walkthrough

This change refactors the Payment Gateway Account DocType to resolve a reference to a deleted Payment Gateway DocType. The hardcoded "payment_gateway" Link field is removed from the DocType JSON schema and replaced with a migration patch that conditionally creates it as a custom field when the payments application is installed. The payment_channel field type definition is also expanded to support an "Other" option.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

• Verify the custom field creation in the patch matches the original field properties (fieldtype, options, required status, in_list_view)
• Confirm the conditional check for the "payments" app installation is correct
• Ensure the patch execution order in patches.txt doesn't conflict with model sync operations
• Validate that cache clearing after custom field creation is appropriate

Suggested labels

accounts, needs-tests, backport version-15-hotfix

Suggested reviewers

• ruthra-kumar

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and concisely summarizes the main change: removing the payment_gateway field from the Payment Gateway Account DocType, which directly addresses the issue.
Description check	✅ Passed	The description accurately explains the changes made: removing the payment_gateway field and adding a patch for custom field creation if the payments app is installed, with proper issue references.
Linked Issues check	✅ Passed	The PR successfully addresses the core requirement of issue #45220 by removing the reference to the deleted Payment Gateway DocType from Payment Gateway Account while preserving functionality through a custom field patch.
Out of Scope Changes check	✅ Passed	All changes are directly related to resolving the broken reference issue: removing the field, adding the custom field patch, updating the payment_channel type options, and registering the patch. No extraneous modifications detected.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (2)

erpnext/patches/v16_0/create_payment_gateway_account_custom_fields.py (1)

5-22: Patch logic for conditional Custom Field creation looks solid; consider UX placement and late-install cases.

The execute implementation correctly gates on the payments app, uses create_custom_fields in the expected way, and clears the doctype cache, so it should be safe and idempotent for existing sites with payments installed.

Two points to double‑check:

• If a site installs the payments app after this ERPNext patch has already run, this patch will not re‑execute, so payment_gateway will not be auto‑created there. That may be fine given the stated goal ("if the payments app is already installed"), but it’s worth confirming that payments itself covers this scenario or that it’s explicitly out of scope.
• Without an insert_after, the new custom field will appear at the end of the form instead of where the core field used to sit. If you care about preserving the previous layout, you might want to add e.g. "insert_after": "payment_channel" (or "company") to the field dict.

erpnext/patches.txt (1)

452-452: Confirm ordering vs delete_payment_gateway_doctypes and behavior across app combinations.

Registering erpnext.patches.v16_0.create_payment_gateway_account_custom_fields in the post_model_sync block, after erpnext.patches.v15_0.delete_payment_gateway_doctypes, is consistent with using create_custom_fields (schema is already in place) and ensures the new Custom Field is not seen by the delete patch.

Given the history behind issue #45220, it would be good to explicitly confirm:

• On sites where payments is not installed, delete_payment_gateway_doctypes behaves as intended and this new patch remains a no-op.
• On sites where payments is installed, delete_payment_gateway_doctypes does not end up deleting the Payment Gateway DocType that payments owns, and the new custom payment_gateway link created here points at the correct surviving DocType.

If this interaction is already covered by tests or by safeguards inside delete_payment_gateway_doctypes, a brief note in the PR description or a comment in that patch might help future readers.

📜 Review details

Configuration used: Path: .coderabbit.yml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between d3c33d1 and 0abbbcd.

📒 Files selected for processing (4)

• erpnext/accounts/doctype/payment_gateway_account/payment_gateway_account.json (1 hunks)
• erpnext/accounts/doctype/payment_gateway_account/payment_gateway_account.py (1 hunks)
• erpnext/patches.txt (1 hunks)
• erpnext/patches/v16_0/create_payment_gateway_account_custom_fields.py (1 hunks)

🧰 Additional context used

🧬 Code graph analysis (1)

erpnext/patches/v16_0/create_payment_gateway_account_custom_fields.py (1)

erpnext/support/doctype/service_level_agreement/service_level_agreement.py (2)

• create_custom_fields (288-309)
• clear_cache (252-254)

🪛 Ruff (0.14.5)

erpnext/accounts/doctype/payment_gateway_account/payment_gateway_account.py

23-23: Syntax error in forward annotation: Expected an expression

(F722)

---

23-23: Undefined name Email

(F821)

---

23-23: Undefined name Phone

(F821)

---

23-23: Undefined name Other

(F821)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (6)

• GitHub Check: Python Unit Tests (3)
• GitHub Check: Python Unit Tests (1)
• GitHub Check: Patch Test
• GitHub Check: Python Unit Tests (4)
• GitHub Check: Python Unit Tests (2)
• GitHub Check: Summary

🔇 Additional comments (2)

erpnext/accounts/doctype/payment_gateway_account/payment_gateway_account.py (1)

23-23: Literal type update correctly tracks the new "Other" option; verify static-analysis behavior.

Expanding the payment_channel hint to DF.Literal["", "Email", "Phone", "Other"] matches the updated Select options in the DocType JSON and keeps type-checkers honest; the change is confined to the TYPE_CHECKING block so it has no runtime impact.

Ruff’s F722/F821 hints here look like a quirk of how it parses the DF.Literal[...] pattern rather than a real Python issue, but if CI is actually failing on these, you may need to either (a) adjust the Ruff configuration for this file/line, or (b) fall back to a looser annotation (e.g. DF.Data) for this one field.

erpnext/accounts/doctype/payment_gateway_account/payment_gateway_account.json (1)

7-76: Core payment_gateway field removal relies entirely on the new Custom Field patch; confirm behavior when payments is absent.

The DocType JSON now no longer defines a core payment_gateway field, which addresses the “deleted DocType is still referenced” issue and is consistent with re‑introducing it via a Custom Field only when the payments app is installed.

Given that the Python controller (PaymentGatewayAccount.autoname) still uses self.payment_gateway, please verify:

• For sites with payments installed, the new patch reliably creates the payment_gateway Custom Field so existing logic and data continue to work.
• For sites without payments, it’s acceptable that Payment Gateway Account no longer exposes payment_gateway at all and that autoname may see an empty value (i.e., this doctype isn’t expected to be used there).

If you expect Payment Gateway Account to never be used without payments, a brief comment in the controller or DocType description might help future maintainers understand this coupling.

Also applies to: 80-80