oluexpert99 opened a new pull request, #6180:
URL: https://github.com/apache/fineract/pull/6180
- Downloading the savings, recurring-deposit or fixed-deposit
transaction template
failed with HTTP 500 (IllegalArgumentException: The workbook already
contains this
name: Account_<client>_<id>_) on tenants where one client holds more
than one
account. The template is unusable for the whole tenant; there is no
API workaround.
- setNames builds one Account_<client>_<id>_ defined name per client,
collecting
clients by walking the account lookup table and starting a new run
whenever the
client name changes. That run detection uses a case-sensitive
String.equals, but the
table it walks was just sorted with
SavingsAccountData.ClientNameComparator, which
compares the names case-INSENSITIVELY (both upper-cased). Two
clients whose names
differ only in case therefore compare equal to the sort and may be
interleaved, which
splits one client's accounts into two runs; the second run re-adds
the same client
and the per-client loop then asks POI to create a defined name that
already exists.
- Guard the collection so a client name that has already been recorded
is not added
again, mirroring the guard LoanRepaymentWorkbookPopulator.setNames
already has. Each
client contributes exactly one defined name, whatever its account
count; nothing
changes for tenants that never hit the collision.
- Apply the same guard to all three affected populators
(SavingsTransactionsWorkbookPopulator,
RecurringDepositTransactionWorkbookPopulator,
FixedDepositTransactionWorkbookPopulator), which carry identical
copies of the loop.
- Add a unit test per populator: three accounts (client 18, client 19
whose name
differs from 18's only in case, then client 18 again) reproduce the
split-run
ordering. Each test fails on the unfixed code with the exact
production exception and
asserts one defined name per client, still distinct when upper-cased
since Excel
defined names are case-insensitive.
## Description
Describe the changes made and why they were made. (Ignore if these details
are present on the associated Apache Fineract JIRA ticket.)
## Checklist
Please make sure these boxes are checked before submitting your pull request
- thanks!
- [ ] Write the commit message as per [our
guidelines](https://github.com/apache/fineract/blob/develop/CONTRIBUTING.md#pull-requests)
- [ ] Acknowledge that we will not review PRs that are not passing the build
_("green")_ - it is your responsibility to get a proposed PR to pass the build,
not primarily the project's maintainers.
- [ ] Create/update [unit or integration
tests](https://fineract.apache.org/docs/current/#_testing) for verifying the
changes made.
- [ ] Follow our [coding
conventions](https://cwiki.apache.org/confluence/display/FINERACT/Coding+Conventions).
- [ ] Add required Swagger annotation and update API documentation at
fineract-provider/src/main/resources/static/legacy-docs/apiLive.htm with
details of any API changes
- [ ] [This PR must not be a "code
dump"](https://cwiki.apache.org/confluence/display/FINERACT/Pull+Request+Size+Limit).
Large changes can be made in a branch, with assistance. Ask for help on the
[developer mailing list](https://fineract.apache.org/#contribute).
- [ ] If merging this PR resolves a JIRA issue, I will mark that issue as
resolved and set "Fix Version/s" appropriately.
Your assigned reviewer(s) will follow our [guidelines for code
reviews](https://cwiki.apache.org/confluence/display/FINERACT/Code+Review+Guide).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
