Foo Developer created FINERACT-2690:
---------------------------------------
Summary: Undo account transfer resolves against the wrong id and
can over-reverse recurring transfer
Key: FINERACT-2690
URL: https://issues.apache.org/jira/browse/FINERACT-2690
Project: Apache Fineract
Issue Type: Bug
Components: Loan, Savings
Reporter: Foo Developer
AccountTransfersWritePlatformServiceImpl.undo() (the undo-account-transfer
capability added
in FINERACT-2604 for savings-to-loan and extended in FINERACT-2613 for
savings-to-savings)
has two related defects:
1. Wrong lookup table. undo() resolves the path id against
m_account_transfer_details, but
the transfer read/list APIs
(AccountTransfersReadPlatformServiceImpl.retrieveOne, which
queries by att.id) expose m_account_transfer_transaction.id instead. These
are two
independent id sequences that drift apart over time, so a call to undo a
transfer that
is clearly visible via the list/read endpoints can 404.
2. Over-reversal on recurring transfers. undo() reverses every
AccountTransferTransaction
tied to the resolved AccountTransferDetails record, instead of only the
single transaction
the caller asked to undo. This incorrectly reverses every execution of a
recurring
transfer (e.g. a standing instruction) that shares one details row across
many runs.
3. Missing permission. The command handler wires the undo command to
actionName=UNDO / entityName=ACCOUNTTRANSFER, but no matching m_permission
row
(UNDO_ACCOUNTTRANSFER) was ever shipped, so the command fails permission
validation
before it can even reach the above logic.
Proposed fix: resolve and scope undo() by m_account_transfer_transaction id
rather than
the details record, for both the savings-to-loan and savings-to-savings paths,
and add
the missing UNDO_ACCOUNTTRANSFER permission via a changelog migration.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
