Farooq Ayoade created FINERACT-2708:
---------------------------------------
Summary: Bulk-import savings/recurring/fixed-deposit transaction
download templates throw HTTP 500 (IllegalArgumentException: The workbook
already contains this name) when a client has more than one account
Key: FINERACT-2708
URL: https://issues.apache.org/jira/browse/FINERACT-2708
Project: Apache Fineract
Issue Type: Bug
Components: DataImportTool
Reporter: Farooq Ayoade
h3. Observed behavior
{{GET /v1/savingsaccounts/transactions/downloadtemplate}} returns HTTP 500 on a
tenant where a client has more than one savings account:
java.lang.IllegalArgumentException: The workbook already contains this name:
Account_maryam_yusuf_18_
at org.apache.poi.hssf.usermodel.HSSFWorkbook.createName(HSSFWorkbook.java)
at
org.apache.fineract.infrastructure.bulkimport.populator.savings.SavingsTransactionsWorkbookPopulator.setNames(SavingsTransactionsWorkbookPopulator.java:240)
at ...SavingsTransactionsWorkbookPopulator.setRules(...)
at ...SavingsTransactionsWorkbookPopulator.populate(...)
h3. Expected behavior
The template downloads successfully (HTTP 200). Each client contributes exactly
one {{Account_<client>_<id>_}} Excel defined name (the dropdown source of that
client's accounts), regardless of how many accounts the client has.
h3. Steps to reproduce
# Create a client with *two or more* savings accounts (e.g. client "Maryam
Yusuf", two active accounts).
# {{{}GET
/fineract-provider/api/v1/savingsaccounts/transactions/downloadtemplate?dateFormat=dd%20MMMM%20yyyy{}}}.
# Observe HTTP 500 with the {{The workbook already contains this name:
Account_<client>_<id>_}} exception.
h3. Root cause
{{SavingsTransactionsWorkbookPopulator.setNames()}} builds the per-client
account dropdown named ranges by walking the (client-name-sorted) account list
and, on each client-name transition, appending to {{clientsWithActiveSavings}}
{*}without a de-duplication guard{*}:
clientsWithActiveSavings.add(clientName); // no "already added?" check
clientIdsWithActiveSavings.add(clientId);
It then creates one Excel defined name per entry:
for (int j = 0; j < clientsWithActiveSavings.size(); j++) {
Name name = workbook.createName();
setSanitized(name, "Account_" + clientsWithActiveSavings.get(j) + "_" +
clientIdsWithActiveSavings.get(j) + "_");
...
}
When the same client name recurs in the account list, the client is added twice
and {{createName}} is called with the same {{Account_<client>_<id>_}} twice →
POI rejects the duplicate defined name → HTTP 500.
The *loan-repayment* template does not have this bug because
{{LoanRepaymentWorkbookPopulator.setNames()}} guards the append:
{{if (!clientsWithActiveLoans.contains(clientName)) \{
clientsWithActiveLoans.add(clientName);
clientIdsWithActiveLoans.add(clientId);
}}}
The same guard is missing from *savings-transaction,
recurring-deposit-transaction and fixed-deposit-transaction* populators.
h3. Proposed fix
Add the same de-duplication guard the loan-repayment populator already uses to
{{SavingsTransactionsWorkbookPopulator.setNames()}} (and the RD/FD-transaction
populators), so each client produces a single {{Account_<client>_<id>_}}
defined name.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
