Samer-Melhem-FOO opened a new pull request, #6528:
URL: https://github.com/apache/fineract/pull/6528

   ## Description
   
   JIRA: [FINERACT-2865](https://issues.apache.org/jira/browse/FINERACT-2865)
   
   A non-repeating calendar is stored with `recurrence = NULL`. Both row 
mappers in `CalendarReadPlatformServiceImpl` (`CalendarDataMapper`, 
`CalendarDataFromHistoryMapper`) passed that null to 
`CalendarUtils.getFrequency` / `getInterval` / `getRepeatsOnDay` / 
`getRepeatsOnNthDayOfMonth` / `getMonthOnDay`, whose ical4j `RRule` parsing 
throws a `NullPointerException`, so any read of such a calendar failed with 
HTTP 500.
   
   The fix guards those five calls with the same `recurrence != null` check the 
mappers already use for `humanReadable`, and falls back to 
`CalendarFrequencyType.INVALID`, `0`, `CalendarWeekDaysType.INVALID`, 
`NthDayType.INVALID` and `null`. Repeating calendars are mapped exactly as 
before.
   
   ### Testing
   
   - New `CalendarReadPlatformServiceImplTest`: maps a non-repeating row (null 
recurrence) through `retrieveCalendar` (fails on `develop` with the NPE, passes 
with the fix) and a repeating weekly row (rule still parsed). 
`CalendarUtilsTest` still passes; `spotlessJavaCheck`, `checkstyleMain`, 
`checkstyleTest` clean.
   - Checked manually on a local `develop` build (PostgreSQL): created a group 
with a non-repeating GENERAL calendar (`typeId: 4, repeating: false`) and a 
repeating weekly one. Before the change `GET 
/v1/groups/{id}/calendars/{calendarId}`, `GET /v1/groups/{id}/calendars` and 
`GET /v1/loans/template?templateType=jlgbulk&groupId={id}` returned HTTP 500 
(NPE in `CalendarUtils.getICalRecur`); after it all three return 200, the 
non-repeating calendar with `repeating: false, interval: 0` and no `frequency` 
/ `repeatsOnDay`. The repeating calendar's response is unchanged.
   
   ## 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.
   - [x] 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).
   - [x] 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 (no API change)
   - [x] [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).
   - [x] If merging this PR resolves a JIRA issue, I will mark that issue as 
resolved and set "Fix Version/s" appropriately.
   - [x] I followed the [AI 
Policy](https://github.com/apache/fineract/blob/develop/CONTRIBUTING.md#ai-policy).
   
   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]

Reply via email to