[NAE-2423] Extend Action API with wrapper support#440
Conversation
Introduced methods to handle additional parameters across case and task search and count operations. Created a constants class for default process parameter names and added overloads with parameter maps to improve flexibility.
Replaced the `AuthPrincipalDto` class with a Java record for improved immutability and concise representation. Adjusted related code to align with the record's accessors and updated the system username constant in `UserConstants` for consistency.
WalkthroughThis PR extends search and count operations with parameterized variants, converts AuthPrincipalDto to an immutable record, and introduces system user and default parameter name constants. ActionApi interface gains six overloads accepting params; ActionApiImpl implements these by delegating params-less calls through empty HashMap and refactors elastic logic to use record accessors. UserServiceImpl is corrected to use the new constant. ChangesData model and constants
🎯 3 (Moderate) | ⏱️ ~20 minutes Suggested labels
🚥 Pre-merge checks | ✅ 3 | ❌ 2❌ Failed checks (1 warning, 1 inconclusive)
✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Warning Review ran into problems🔥 ProblemsGit: Failed to clone repository. Please run the Tip 💬 Introducing Slack Agent: The best way for teams to turn conversations into code.Slack Agent is built on CodeRabbit's deep understanding of your code, so your team can collaborate across the entire SDLC without losing context.
Built for teams:
One agent for your entire SDLC. Right inside Slack. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In
`@application-engine/src/main/java/com/netgrif/application/engine/actions/ActionApiImpl.java`:
- Around line 125-128: The new params-aware overloads (e.g.,
ActionApiImpl.searchCases(String processIdentifier, Predicate predicate,
Pageable pageable, Map<String,String> params)) currently ignore the params map;
update each of these methods to incorporate or forward params into the
search/count operation instead of discarding them. Concretely: in searchCases
and the analogous countCases wrappers, either merge params into the existing
Predicate (e.g., build or augment predicate from params) or call the
workflowService overload that accepts params (e.g., workflowService.search(...)
/ workflowService.count(...) with params) so the incoming Map<String,String> is
actually used; apply the same change to every method signature that accepts
Map<String,String> params in this class. Ensure you reference and update the
methods named searchCases and the corresponding countCases wrappers so params
are read and propagated to workflowService.
In
`@nae-object-library/src/main/java/com/netgrif/application/engine/objects/auth/dto/AuthPrincipalDto.java`:
- Around line 11-16: AuthPrincipalDto is a Java record whose compiler-generated
equals, hashCode and toString include sessionId despite Lombok annotations; to
fix this either convert the record to a class-based DTO or add an explicit
record body that overrides equals(Object), hashCode(), and toString() to exclude
the sessionId component (keep the existing components username and realmId
semantics and retain Serializable), ensuring all loggable toString() calls and
equality/hash checks do not expose sessionId.
In
`@nae-spring-core-adapter/src/main/java/com/netgrif/application/engine/adapter/spring/actions/ActionApi.java`:
- Around line 216-223: The Javadoc for the countTasks method incorrectly states
it returns "a page of tasks"; update the `@return` description for the countTasks
method to reflect that it returns a Long representing the count of tasks (e.g.,
"the number of tasks matching the criteria") so the documentation matches the
method's return type Long in ActionApi.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: c8e2e965-a2aa-4753-92f2-6f91200ee187
📒 Files selected for processing (6)
application-engine/src/main/java/com/netgrif/application/engine/actions/ActionApiImpl.javanae-object-library/src/main/java/com/netgrif/application/engine/objects/auth/constants/UserConstants.javanae-object-library/src/main/java/com/netgrif/application/engine/objects/auth/dto/AuthPrincipalDto.javanae-spring-core-adapter/src/main/java/com/netgrif/application/engine/adapter/spring/actions/ActionApi.javanae-spring-core-adapter/src/main/java/com/netgrif/application/engine/adapter/spring/actions/ActionApiDefaultParamNames.javanae-user-ce/src/main/java/com/netgrif/application/engine/auth/service/UserServiceImpl.java
| public Page<Case> searchCases(String processIdentifier, Predicate predicate, Pageable pageable, Map<String, String> params) { | ||
| log.debug("Searching cases for process identifier [{}] with predicate [{}], pageable [{}]", processIdentifier, predicate, pageable); | ||
| return workflowService.search(predicate, pageable); | ||
| } |
There was a problem hiding this comment.
params is ignored in all new params-aware search/count overloads.
Lines 125–128, 131–139, 142–150, 186–189, 192–200, and 203–211 accept Map<String, String> params but never read or propagate it. This leaves the new wrapper/default-param contract effectively unimplemented.
Also applies to: 131-139, 142-150, 186-189, 192-200, 203-211
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In
`@application-engine/src/main/java/com/netgrif/application/engine/actions/ActionApiImpl.java`
around lines 125 - 128, The new params-aware overloads (e.g.,
ActionApiImpl.searchCases(String processIdentifier, Predicate predicate,
Pageable pageable, Map<String,String> params)) currently ignore the params map;
update each of these methods to incorporate or forward params into the
search/count operation instead of discarding them. Concretely: in searchCases
and the analogous countCases wrappers, either merge params into the existing
Predicate (e.g., build or augment predicate from params) or call the
workflowService overload that accepts params (e.g., workflowService.search(...)
/ workflowService.count(...) with params) so the incoming Map<String,String> is
actually used; apply the same change to every method signature that accepts
Map<String,String> params in this class. Ensure you reference and update the
methods named searchCases and the corresponding countCases wrappers so params
are read and propagated to workflowService.
| public record AuthPrincipalDto(String username, | ||
| String realmId, | ||
| @ToString.Exclude | ||
| @EqualsAndHashCode.Exclude | ||
| @JsonIgnore | ||
| String sessionId) implements Serializable { |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
In Java records, are all record components always included in compiler-generated equals/hashCode/toString? Do Lombok @ToString.Excludeand@EqualsAndHashCode.Exclude on record components alter those generated record methods?
💡 Result:
In Java records, the compiler-generated equals, hashCode, and toString methods are always based on all record components [1][2]. These methods are implicitly declared by the compiler to ensure that two record instances are considered equal if they are of the same type and contain equal component values, and that the toString representation includes all components [3][2]. Lombok annotations such as @ToString.Exclude and @EqualsAndHashCode.Exclude do not alter the compiler-generated methods of a Java record [4]. These Lombok annotations are designed to work with standard Java classes (POJOs) by modifying the code generated by the Lombok annotation processor [5][6][7]. Because Java records have their own built-in, compiler-driven implementation for these methods, Lombok's annotation processor does not intercept or modify them [4][8]. If you need to exclude specific components from equals, hashCode, or toString in a record, you must manually override the corresponding methods in the record body [9][10]. When doing so, it is recommended to maintain the expected semantic invariants of the record [11][3].
Citations:
- 1: https://docs.oracle.com/en/java/javase/26/language/records.html
- 2: https://docs.oracle.com/en/java/javase/25/docs/api//java.base/java/lang/Record.html
- 3: https://docs.oracle.com/en/java/javase/16/docs/specs/records-jls.html
- 4: [FEATURE] Add support for records in @ToString or add new annotation to exclude params to not show in toString method projectlombok/lombok#3452
- 5: https://stackoverflow.com/questions/56263350/lombok-excluding-field-with-tostring-exclude-is-not-working
- 6: https://projectlombok.org/features/ToString
- 7: https://projectlombok.org/api/lombok/EqualsAndHashCode.Exclude
- 8: https://blog.stackademic.com/migrating-lombok-annotations-to-java-records-a-complete-guide-ddf939407581
- 9: https://stackoverflow.com/questions/61719589/do-you-need-to-override-hashcode-and-equals-for-records
- 10: https://stackoverflow.com/questions/61719589/do-you-need-to-override-hashcode-and-equals-for-records/61719753
- 11: https://openjdk.org/jeps/395?accessToken=eyJhbGciOiJIUzI1NiIsImtpZCI6ImRlZmF1bHQiLCJ0eXAiOiJKV1QifQ.eyJhdWQiOiJhY2Nlc3NfcmVzb3VyY2UiLCJleHAiOjE2NDc4Mjg4MTYsImciOiJlckFkUHk4WE1ZSU1ncEFHIiwiaWF0IjoxNjQ3ODI4NTE2LCJ1c2VySWQiOjYyMzI4fQ.ynfOAzT-LRbKklQwjiPLeDa_CCI6bOqgCISpiPyC3dE
🏁 Script executed:
# First, locate and examine the AuthPrincipalDto file
find . -name "AuthPrincipalDto.java" -type fRepository: netgrif/application-engine
Length of output: 175
🏁 Script executed:
# Check if the file has any method overrides for equals/hashCode/toString
rg -A 20 "record AuthPrincipalDto" --type javaRepository: netgrif/application-engine
Length of output: 1402
🏁 Script executed:
# Search for usage of AuthPrincipalDto in logging contexts, particularly in ActionApiImpl
rg "AuthPrincipalDto" --type java -B 2 -A 2Repository: netgrif/application-engine
Length of output: 20840
Lombok exclusion annotations do not affect record-generated equals, hashCode, or toString.
The sessionId component is included in all three record-generated methods despite the @ToString.Exclude and @EqualsAndHashCode.Exclude annotations. Since AuthPrincipalDto is logged directly in multiple places (e.g., ActionApiImpl.java log statements), the sessionId is exposed in logs via toString().
To preserve the exclusion semantics, override equals, hashCode, and toString in the record body, or revert to a class-based DTO.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In
`@nae-object-library/src/main/java/com/netgrif/application/engine/objects/auth/dto/AuthPrincipalDto.java`
around lines 11 - 16, AuthPrincipalDto is a Java record whose compiler-generated
equals, hashCode and toString include sessionId despite Lombok annotations; to
fix this either convert the record to a class-based DTO or add an explicit
record body that overrides equals(Object), hashCode(), and toString() to exclude
the sessionId component (keep the existing components username and realmId
semantics and retain Serializable), ensuring all loggable toString() calls and
equality/hash checks do not expose sessionId.
| * Counts tasks using elastic search queries. | ||
| * | ||
| * @param elasticStringQueries a list of queries for filtering tasks | ||
| * @param authPrincipalDto the authorization principal used for the search | ||
| * @param isIntersection true to intersect results of all queries; false for union | ||
| * @param params additional params for the operation | ||
| * @return a page of tasks matching the criteria | ||
| */ |
There was a problem hiding this comment.
Fix Javadoc return type description for countTasks.
Line 222 says “a page of tasks,” but this method returns Long. Please update the return description to prevent API-doc confusion.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In
`@nae-spring-core-adapter/src/main/java/com/netgrif/application/engine/adapter/spring/actions/ActionApi.java`
around lines 216 - 223, The Javadoc for the countTasks method incorrectly states
it returns "a page of tasks"; update the `@return` description for the countTasks
method to reflect that it returns a Long representing the count of tasks (e.g.,
"the number of tasks matching the criteria") so the documentation matches the
method's return type Long in ActionApi.
Description
Implements NAE-2423
Dependencies
No new dependencies were introduced
Third party dependencies
No new dependencies were introduced
Blocking Pull requests
There are no dependencies on other PR
How Has Been This Tested?
This was tested manually and with unit tests.
Test Configuration
Checklist:
Summary by CodeRabbit
New Features
Bug Fixes
Refactor