Add eventType filtering support in AuditLog REST API

[Archii1201]

This PR introduces support for filtering audit logs by eventType in the REST API.

Currently, the API supports filtering by user, date range, and entity type. This change extends the filtering capability by allowing clients to specify an eventType (e.g., ADDED, MODIFIED, DELETED).

Changes:

• Added optional eventType query parameter in AuditLogRestController
• Implemented validation and mapping using predefined allowed values
• Added in-memory filtering of results based on eventType
• Included TODO for pushing filtering to service/DAO layer in future

This is an incremental improvement aimed at enhancing audit log querying and aligns with future audit event extensions.

[Archii1201]

Hi, I’m exploring the auditlogweb module as part of my GSoC preparation and started with improving REST API filtering capabilities. Looking forward to feedback.

[Binayak490-cyber]

Hi @Archii1201, have you gone through this before raising this PRs - https://openmrs.atlassian.net/wiki/spaces/docs/pages/25477199/Pull+Request+Tips

[shubhangiisinghh]

Hey @Archii1201 good addition, One concern though, the in memory filtering will get slow as audit logs grow. would it make sense to push the eventType filter down to the DAO/HQL layer so the database handles it? the TODO acknowledges this but ideally it should be resolved here rather than deferred.

[Archii1201]

Hey @Archii1201 good addition, One concern though, the in memory filtering will get slow as audit logs grow. would it make sense to push the eventType filter down to the DAO/HQL layer so the database handles it? the TODO acknowledges this but ideally it should be resolved here rather than deferred.

Hi, thanks for the suggestion — that makes sense.

I agree that pushing the eventType filtering down to the DAO/HQL layer would be more efficient compared to in-memory filtering.

Due to time constraints I implemented the controller-level filtering as an initial step, but I understand the need to move this logic to the database layer for better scalability. I’d be happy to take this up as a follow-up improvement.