oluexpert99 opened a new pull request, #6311:
URL: https://github.com/apache/fineract/pull/6311
FinancialActivityAccountDataValidator validates the same parameter against
two
hand-written lists. validateForCreate accepts all seven FinancialActivity
constants; validateForUpdate accepted five, omitting CASH_AT_MAINVAULT (101)
and CASH_AT_TELLER (102). The platform will therefore create a teller or
vault
mapping and then refuse every attempt to change it:
PUT /financialactivityaccounts/{id} {"financialActivityId":102,...}
400 validation.msg.financialactivityaccount.financialActivityId
.is.not.one.of.expected.enumerations
must be one of [ 100, 200, 300, 103, 201 ]
Both halves write the same column, and the teller module resolves the mapping
through findByFinancialActivityTypeWithNotFoundDetection whichever route
created it, so the two lists have no reason to differ.
These are the GL accounts the cashier module posts cash against. A deployment
that maps them wrongly, which is easy since they are set once at
configuration
time, has every teller and vault movement landing on the wrong account and no
supported way to correct it. The remaining options are to delete the mapping
and create a replacement, discarding the row and its identity, or to update
the
database directly, bypassing validation and the audit trail.
FinancialActivityAccountsTest exercised the update path only with
LIABILITY_TRANSFER, and its negative case used activity id 232, which is not
in
the enum at all. A value that is in the enum, is accepted by create and is
refused by update fell between the two cases. The test now creates a
CASH_AT_TELLER mapping and updates it.
## 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]
