Samer-Melhem-FOO opened a new pull request, #6527: URL: https://github.com/apache/fineract/pull/6527
## Description [FINERACT-2864](https://issues.apache.org/jira/browse/FINERACT-2864) `GET /audits/searchtemplate` and `GET /makercheckers/searchtemplate` return the `AuditSearchData` record directly, so Jersey writes it with the Jackson `objectMapper` (`JerseyJacksonObjectArgumentHandler`) rather than the Gson based `DefaultToApiJsonSerializer` the other endpoints use. Jackson only writes properties that have a getter, and `AppUserData` has none for `id` or `username`, so every entry of `appUsers` is serialized as `{}` and the "User" / "Checker" dropdowns of the audit and checker inbox search screens stay empty. Nothing is logged. The fix adds Lombok `@Getter` to `AppUserData.id` and `AppUserData.username` only, the two fields `AppUserData.dropdown(id, username)` fills for these templates. A class-level `@Getter` is avoided so the other fields (roles, staff, clients, password flags) are not put on the wire through this path. The Gson based endpoints that use `AppUserData` (`/users`, `/users/{id}`, `/users/template`) read fields directly and are unaffected. **Tests** - New `AuditSearchDataSerializationTest` (fineract-provider): writes an `AuditSearchData` with the Jersey `objectMapper` bean and asserts each `appUsers` entry has exactly `id` and `username`. Without the fix it fails (`expected: <[id, username]> but was: <[]>`); with it it passes. `spotlessJavaCheck` (fineract-core, fineract-provider), `checkstyleMain` (fineract-core) and `checkstyleTest` (fineract-provider) are clean. - Checked manually on a local `develop` build (PostgreSQL): before the change both templates returned HTTP 200 with `"appUsers":[{},{},{}]`; after it they return `"appUsers":[{"id":3,"username":"interopUser"},{"id":1,"username":"mifos"},{"id":2,"username":"system"}]`, matching `GET /users`. `GET /users/1`, `GET /users/template` and `GET /audits?makerId=1&paged=true` are 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: the response now carries the `id` / `username` the template was meant to return) - [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]
