[NAE-2243] Dynamic date resolution in Elastic query

[Kovy95]

Description

• add dynamicQuery switch to case search request

Fixes NAE-2243

Dependencies

none

Third party dependencies

• No new dependencies were introduced

Blocking Pull requests

There are no dependencies on other PR

How Has Been This Tested?

manually

Test Configuration

Name	Tested on
OS	linux mint 21
Runtime	node 20.18.0
Dependency Manager	npm 10.8.2
Framework version	angular 17
Run parameters
Other configuration

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• My changes have been checked, personally or remotely, with @...
• I have commented my code, particularly in hard-to-understand areas
• I have resolved all conflicts with the target branch of the PR
• I have updated and synced my code with the target branch
• I have added tests that prove my fix is effective or that my feature works
• New and existing tests pass locally with my changes:
  • Lint test
  • Unit tests
  • Integration tests
• I have checked my contribution with code analysis tools:
  • SonarCloud
  • Snyk
• I have made corresponding changes to the documentation:
  • Developer documentation
  • User Guides
  • Migration Guides

Summary by CodeRabbit

• New Features
  • Enhanced case search functionality with an optional setting to enable dynamic query capabilities, providing flexible query resolution options for advanced search configurations.

[coderabbitai]

Walkthrough

A new optional boolean field dynamicQuery is added to the CaseSearchRequestBody interface to support switching between legacy query resolution and Groovy-based dynamic code evaluation in query processing.

Changes

Cohort / File(s)	Summary
Query Configuration Extension projects/netgrif-components-core/src/lib/filter/models/case-search-request-body.ts	Added optional dynamicQuery?: boolean field to enable selection between traditional query resolution and Groovy-based dynamic query execution

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

Pre-merge checks

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title Check	✅ Passed	The title "NAE-2243 Dynamic date resolution in Elastic query" is partially related to the changeset. The pull request adds an optional dynamicQuery boolean field to the CaseSearchRequestBody interface to enable switching between old query resolution and Groovy-based dynamic code. The title correctly references the dynamic query capability, which is the core aspect of the change, and aligns with the PR objective of adding "a dynamicQuery switch to the case search request." However, the title specifically mentions "date resolution" without explicitly stating that a new field is being added or that this is a configuration switch, making it somewhat less precise than it could be.

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

📜 Review details

Configuration used: CodeRabbit UI

Review profile: ASSERTIVE

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 37711a2 and 5b9b12e.

📒 Files selected for processing (1)

• projects/netgrif-components-core/src/lib/filter/models/case-search-request-body.ts (1 hunks)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (4)

• GitHub Check: Matrix Test (24)
• GitHub Check: Matrix Test (20)
• GitHub Check: Matrix Test (22)
• GitHub Check: Test with SonarCloud

🔇 Additional comments (1)

projects/netgrif-components-core/src/lib/filter/models/case-search-request-body.ts (1)

55-58: Verify security implications of dynamic query execution.

Enabling Groovy-based dynamic code execution in queries raises security concerns. Ensure the backend properly validates and sanitizes inputs to prevent code injection attacks, especially if any part of the query can be influenced by user input.

Please confirm:

1. What input validation exists on the backend for queries when dynamicQuery is enabled?
2. Are there any restrictions on which Groovy expressions can be executed?
3. Is there documentation on safe usage patterns for this feature?

[coderabbitai]

🧹 Nitpick | 🔵 Trivial

Improve documentation clarity.

The JSDoc comment could be more specific and helpful for developers. Consider clarifying:

• What happens when dynamicQuery is true vs false vs undefined (not provided)
• What "the old way" means (e.g., "static query resolution" or "template-based resolution")
• What the Groovy-based dynamic code execution enables
• The default behavior when this field is omitted

Example improvement:

 /**
- * A switch for resolving query the old way or by Groovy compiler for dynamic code in queries.
+ * Controls query resolution mode for the {@link query} field.
+ * 
+ * - `true`: Enables Groovy-based dynamic code evaluation in queries, allowing runtime date resolution and expressions
+ * - `false` or `undefined`: Uses legacy template-based query resolution (default)
+ * 
+ * @default false
  */
 dynamicQuery?: boolean;

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	/**
	* A switch for resolving query the old way or by Groovy compiler for dynamic code in queries.
	*/
	dynamicQuery?: boolean;
	/**
	* Controls query resolution mode for the {@link query} field.
	*
	* - `true`: Enables Groovy-based dynamic code evaluation in queries, allowing runtime date resolution and expressions
	* - `false` or `undefined`: Uses legacy template-based query resolution (default)
	*
	* @default false
	*/
	dynamicQuery?: boolean;

🤖 Prompt for AI Agents

In
projects/netgrif-components-core/src/lib/filter/models/case-search-request-body.ts
around lines 55 to 58, the JSDoc for dynamicQuery is vague; update it to
explicitly state behavior for true, false, and undefined, define what "the old
way" means (e.g., static/template-based resolution), describe what enabling
Groovy-based dynamic execution allows (evaluating dynamic expressions or scripts
in queries), and document the default when omitted; change the comment to
clearly list: true = use Groovy dynamic evaluation, false = use
static/template-based resolution, undefined = use the default behavior (specify
which default your system uses), and note any security/validation considerations
or side effects of enabling Groovy evaluation.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

The base branch was changed.