Aman-Mittal opened a new issue, #788:
URL: https://github.com/apache/fineract-backoffice-ui/issues/788
## Summary
The audit log screen lists audit entries, but an entry can't be opened. An
auditor can't see *what* was changed: the command's JSON payload, the resource
it targeted, or who checked it under maker-checker. The filter options that
Fineract publishes for audit search are not used either.
## Evidence (`main` @ `8da1086f`)
- `api-surface.json` lists `"AuditsService": ["getAudits"]` only. It has no
`getAuditsAuditId` and no `getAuditsSearchtemplate`.
- The screen is
`src/app/features/security/audit-logs/audit-logs-list.component.ts`.
## Platform support
`AuditsApiResource`:
- `GET /v1/audits/{auditId}` returns one entry with `commandAsJson`,
`resourceId`, `subresourceId`, entity and action names, office, group, client,
loan and savings ids, maker and made-on date, checker and checked-on date, and
processing result.
- `GET /v1/audits/searchtemplate` returns the selectable values (`appUsers`,
`actionNames`, `entityNames`, `processingResults`).
- `GET /v1/audits` already supports filtering by `actionName`, `entityName`,
`resourceId`, `makerId`, `makerDateTimeFrom/To`, `checkerId`,
`checkerDateTimeFrom/To`, `processingResult`, `officeId`, `groupId`,
`clientId`, `loanid` and `savingsAccountId`, plus `paged`, `offset`, `limit`,
`orderBy` and `sortOrder`.
## Proposed implementation
- Make rows open a detail view. Show the metadata, links to the affected
client / loan / savings / office, and the pretty-printed `commandAsJson`.
- Mask password-like keys (`password`, `repeatPassword`, `secret`, `token`)
before display.
- Populate the filter bar from `searchtemplate` (user, action, entity,
result, date range) and send the filters server-side with paging.
## RBAC
| Action | Permission code | Typically granted to |
|---|---|---|
| List and open audit entries | `READ_AUDIT` (or `ALL_FUNCTIONS_READ`) |
internal audit, compliance, system administrators |
`READ_AUDIT` is in `scripts/permission-codes.json`.
- Audit entries expose request payloads from every user, which can include
personal data and amounts, so the detail route must be guarded on `READ_AUDIT`
like the list. Branch staff should normally not hold it.
- The UI must never render secrets that appear in a payload; see the masking
above.
- Fineract stores the payload as submitted. Masking is defence in depth and
does not replace `READ_AUDIT` restriction.
### UI expectations
- Use `permissionGuard` on the detail route.
- A user without `READ_AUDIT` gets `/forbidden`, not an empty list.
## Acceptance criteria
- [ ] An audit entry can be opened, showing payload, maker, checker and
linked entities, with secrets masked.
- [ ] Filters from `searchtemplate` work server-side with paging.
- [ ] The detail route is guarded on `READ_AUDIT`.
- [ ] Unit tests cover the masking, the filter-to-query mapping and the
guard.
--
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]
