Samer-Melhem-FOO opened a new pull request, #6199:
URL: https://github.com/apache/fineract/pull/6199
## Description
`StandingInstructionData` declares several fields of type `EnumOptionData`
(`fromAccountType`, `toAccountType`, `transferType`, `instructionType`,
`recurrenceType`, `recurrenceFrequency`). The class also declares same-named
getter methods that return a different, internal domain-enum type instead, e.g.:
```java
public PortfolioAccountType getFromAccountType() {
return Optional.ofNullable(this.fromAccountType).map(e ->
PortfolioAccountType.fromInt(e.getId().intValue())).orElse(null);
}
```
This is confusing to read and maintain: a field and its same-named "getter"
disagree on type. **No behavior or API change**:
`StandingInstructionApiResource` serializes this class via
`DefaultToApiJsonSerializer`, which is Gson-based and reads the raw field
directly regardless of these methods, so today's JSON output is unaffected
either way — but the naming collision is still a latent correctness hazard
(e.g. for anyone who later touches serialization, or adds a getter-based
tool/library) worth removing.
**Change:** rename the six domain-enum helper methods to a distinct `*Enum`
suffix (`getFromAccountTypeEnum()`, `getToAccountTypeEnum()`,
`getTransferTypeEnum()`, `getInstructionTypeEnum()`, `getRecurrenceTypeEnum()`,
`getRecurrenceFrequencyEnum()`) so they no longer shadow the field name, and
add an explicit getter on each underlying field for consistency with the rest
of the class. Internal callers (`StandingInstructionApiResource`,
`ExecuteStandingInstructionsTasklet`) are updated to use the renamed methods,
with added null-safety in `toTransferType()` since the domain-enum helper can
return `null` when the underlying `EnumOptionData` field is `null`.
JIRA: https://issues.apache.org/jira/browse/FINERACT-2723
## Checklist
- [x] Write the commit message as per [our
guidelines](https://github.com/apache/fineract/blob/develop/CONTRIBUTING.md#pull-requests)
- [x] 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.
- [x] 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
- [x] This PR must not be a "code dump". Large changes can be made in a
branch, with assistance.
- [ ] If merging this PR resolves a JIRA issue, I will mark that issue as
resolved and set "Fix Version/s" appropriately.
Note: pure internal rename with no behavior change, so no new test coverage
was added; existing Standing Instruction tests continue to pass unmodified. No
API documentation update needed since there is no API response change.
--
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]
