Ashhar Ahmad Khan created FINERACT-2545:
-------------------------------------------
Summary: Client charge inactivation throws
UnsupportedCommandException — POST command=inactivate has never worked
Key: FINERACT-2545
URL: https://issues.apache.org/jira/browse/FINERACT-2545
Project: Apache Fineract
Issue Type: Bug
Components: Client
Affects Versions: 1.15.0
Reporter: Ashhar Ahmad Khan
POST /clients/\{clientId}/charges/\{chargeId}?command=inactivate throws
UnsupportedCommandException on every call and has never functioned since
it was first wired in the MIFOSX era.
The API accepts the command and builds a CommandWrapper with
entity=CLIENTCHARGE and action=INACTIVATE, but no command handler was
ever registered for the key "CLIENTCHARGE|INACTIVATE". The dispatcher
throws immediately, returning HTTP 500 to every caller.
The service method ClientChargeWritePlatformServiceImpl.inactivateCharge()
was also a stub returning null with the comment
"// functionality not yet supported".
All the surrounding infrastructure was already in place — the DB columns
is_active and inactivated_on_date exist in m_client_charge, the permission
INACTIVATE_CLIENTCHARGE is seeded in 0002_initial_data.xml, the builder
method inactivateClientCharge() exists in CommandWrapperBuilder, and the
API routing at ClientChargesApiResource line 212 correctly accepts the
command. The handler and service implementation were simply never completed.
Savings charges have had a fully working equivalent
(InactivateSavingsAccountChargeCommandHandler) since MIFOSX-1408.
Client charges were left behind.
Fix involves: adding InactivateClientChargeCommandHandler wired to
CLIENTCHARGE|INACTIVATE, implementing ClientCharge.inactivate() on the
domain object, implementing inactivateCharge() in the service with guards
for already-inactive, already-waived, and already-paid states, and an
integration test covering the success path and the idempotency failure case.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
