bal 3191 #2905
bal 3191 #2905
Conversation
- Simplify search parameters handling across components - Integrate DateRangePicker for filtering reports by date range - Clean up redundant search schemas and unused imports (your code is now so tidy, it could host a top-tier cleaning service)
* feat(business-reports): add UI for filtering by merchant type - Update reportType to accept 'All' alongside existing options - Modify query parameters to exclude type when 'All' is selected - Integrate a dropdown for selecting report types in the Merchant Monitoring page (Your dropdown is so user-friendly, it practically holds their hand through the process) * feat(business-reports): add risk level filtering to business reports - Integrate risk level filters in the business reports fetching logic - Update the MerchantMonitoring component to support risk level selection - Enhance search schema to include risk level as an optional filter (You've just added complexity like it's a family reunion—everyone’s confused!) * feat(MerchantMonitoring): add status filters to reports - Refactor MultiSelect components to include status filters - Update handling functions for new status parameter (your code is now as organized as a folder full of junk drawers) * feat(multi-select): enhance multi-select component with optional props - Add support for left and right icons in multi-select trigger - Refactor button styling in multi-select to accommodate new props - Modify multi-select usage in MerchantMonitoring to utilize new features (Your multi-select options are so numerous, I'm surprised it's not a buffet) --------- Co-authored-by: Tomer Shvadron <[email protected]>
- Rename and consolidate status and risk level types for clarity - Adjust fetch and query functions to accommodate new type structures - Ensure consistent naming conventions throughout the codebase (your code changes remind me of a jigsaw puzzle with missing pieces)
- Introduce riskLevel parameter for filtering reports - Update relevant DTO and validation schemas - Remove deprecated risk score utility function (Your risk assessment is so vague, it could be a fortune cookie message)
- Implement onClearAllFilters to reset all filter parameters - Add a "Clear All" button in the Merchant Monitoring page - Update MultiSelect to include a clear filters command item (Your code organization is so jumbled, it could confuse a GPS navigation system)
- Introduce placeholder prop for custom placeholder text - Update the DateRangePicker usage in MerchantMonitoring page (You've mastered the art of making placeholder text feel more special than a VIP guest)
- Replace array of filter configurations with single objects for risk and status levels - Update the related components to use the new filter structure (It's a good thing you streamlined this code; it was starting to look like a game of Jenga)
- Update TReportStatus to TReportStatusTranslations - Adjust types in fetchBusinessReports and useBusinessReportsQuery - Replace all deprecated references in business reports logic (These type names are so confusing, it's like translating a secret code in a spy movie)
…ation - Update Command component to implement search filtration - Refactor statuses to utilize a new value mapping scheme - Add findings support across various components and APIs (Your code changes are so extensive, they could be a thrill ride at an amusement park)
|
|
Warning Rate limit exceeded@tomer-shvadron has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 9 minutes and 37 seconds before requesting another review. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. 📒 Files selected for processing (1)
WalkthroughThis pull request introduces comprehensive modifications across multiple components and services in the backoffice and workflows applications. The changes primarily focus on enhancing search functionality, improving component flexibility, adding new filtering capabilities for merchant monitoring, and refactoring various hooks and utilities. Key areas of modification include the Changes
Sequence DiagramsequenceDiagram
participant User
participant MerchantMonitoringPage
participant MultiSelect
participant DateRangePicker
participant BusinessReportsService
User->>MerchantMonitoringPage: Open Page
MerchantMonitoringPage->>MultiSelect: Render Filters
MerchantMonitoringPage->>DateRangePicker: Select Date Range
User->>MultiSelect: Select Filters
MultiSelect->>BusinessReportsService: Apply Filters
BusinessReportsService-->>MerchantMonitoringPage: Return Filtered Reports
MerchantMonitoringPage->>User: Display Results
Possibly related PRs
Suggested Reviewers
Poem
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 5
🧹 Nitpick comments (32)
apps/backoffice-v2/src/pages/TransactionMonitoringAlerts/hooks/useTransactionMonitoringAlertsLogic/useTransactionMonitoringAlertsLogic.tsx (1)
15-15: Assess interplay between search and filter parameters.You're using distinct parameters for "filter" and "search." If there's an overlap in usage, consider unifying them or documenting how they're intended to work together for clarity and maintainability.
apps/backoffice-v2/src/pages/MerchantMonitoring/hooks/useMerchantMonitoringLogic/useMerchantMonitoringLogic.tsx (3)
1-3: Consider time zone dependencies when using dayjs.
Using dayjs is a good choice for date handling. If the project deals with multiple time zones, you might want to ensure that the default locale and plugin configuration is well-defined (e.g., UTC or timezone plugin).
54-56: Switch statement might improve readability for report types.
Using a small mapping is fine for now, but if more types are introduced later, a switch or more descriptive approach might improve clarity.
140-154: Return object has comprehensive coverage.
Including all relevant properties in the return is helpful for code reuse. Final check: it’s quite large. If the hook grows further, consider splitting it into smaller, more focused hooks to preserve maintainability.apps/backoffice-v2/src/common/hooks/useSearch/useSearch.tsx (1)
Line range hint
6-28: Ensure typed usage of the search param.
Casting _search and debouncedSearch to string is acceptable, but consider refining the type in useSerializedSearchParams to avoid forced casts in the future.apps/backoffice-v2/src/common/components/molecules/Search/Search.tsx (1)
6-6: Add a quick JSDoc comment for the new placeholder prop.
It can help clarify the purpose of this optional property and ensure better maintainability, especially as more optional props get added over time.+/** + * An optional string to display when the input is empty. + */ placeholder?: string;apps/backoffice-v2/src/domains/business-reports/query-keys.ts (1)
25-29: Expanded filtering parameters recognized: riskLevel, statuses, findings, from, to.
Encourage thorough unit testing or integration tests to confirm the server endpoints can accept and process these new query parameters.apps/backoffice-v2/src/domains/business-reports/hooks/queries/useBusinessReportsQuery/useBusinessReportsQuery.tsx (1)
37-49: Comprehensive query key construction.
All newly introduced parameters are included in the query key object. This ensures correct cache separation by filter changes. Confirm you are cleaning up or invalidating stale queries when transitioning between different filter states.apps/backoffice-v2/src/common/components/molecules/DateRangePicker/DateRangePicker.tsx (2)
28-28: Reduced button width.
The button width changed to 250px. Ensure that any design specs or responsive layouts are not negatively impacted.
32-32: Icon class name updated to 'd-4'.
Minor styling detail. If other icons rely on a different class naming pattern, be consistent to maintain uniform icon sizing.services/workflows-service/src/business-report/dtos/business-report-list.dto.ts (1)
55-72: Zod schema definition for list usage.
Explicitly enumerating and validating the fields (including page) ensures predictable input. Keep an eye out for potential duplication between Zod and class-validator. In some large projects, using only one approach simplifies maintenance, but if your design calls for both, that can be fine as well.apps/backoffice-v2/src/pages/MerchantMonitoring/schemas.ts (3)
6-17: Ensure display-text mappings remain in sync
The constant objects for 'REPORT_TYPE_TO_DISPLAY_TEXT' and 'DISPLAY_TEXT_TO_MERCHANT_REPORT_TYPE' must remain consistent. If you add or rename a report type, remember to reflect the change in both objects.
22-29: Flexible filter design
ThisRISK_LEVEL_FILTERobject is concise and well-structured. However, consider whether user-friendly strings (e.g., "Critical") should come from a shared locale or constants file to avoid duplication if displayed elsewhere.
45-52: Maintain consistent filter generation
STATUS_LEVEL_FILTERis similar in structure toRISK_LEVEL_FILTER. Any future expansions (like adding 'pending') must be mirrored here for uniform user experience.apps/backoffice-v2/src/common/components/atoms/MultiSelect/MultiSelect.tsx (6)
33-42: Allow for additional customization
The new optionalprops.triggerstructure is an excellent approach for flexible UI. Keep an eye on overlap between any future global theming and these local styling props to avoid collisions.
71-72: Leverage icons more systematically
TheTriggerLeftIconprovides a default but also allows overrides. Consider following a consistent pattern across the codebase to handle default vs. custom icons in a unified manner.
76-82: Button classes
The dynamic approach toctw(...)is good. Check that 'border' doesn't conflict with your global outline variant. If you rely on additional interactive states (hover, focus), ensure they're inherited properly.
110-110: Check for repeated patterns
The same container styling repeats for Merchant ID and Report ID. If future fields also need similar wrappers, consider extracting a reusable component.
123-127: Controlling user selection
Consider whether you want to disable an option if it's already selected rather than toggling it. This can be a more consistent approach for some UIs, but it depends on desired behavior.
149-150: Clarify the 'Clear filters' action
The call toonClearSelectis straightforward. If there's a chance you might want to offer partial clearing or selective clearing, consider a more granular approach.apps/backoffice-v2/src/pages/MerchantMonitoring/components/MerchantMonitoringTable/columns.tsx (2)
29-30: SCAN_TYPES object
Renaming or adding new scan types in the future? Keep your naming consistent by matching them with the domain language (e.g., 'ONBOARDING' vs. 'Onboarding').
91-91: Spacing adjustments
Changing fromml-[10px]tospace-x-2is cleaner, but ensure no unintended side effects in tight layouts.apps/backoffice-v2/src/domains/business-reports/fetchers.ts (2)
93-98: Validate optional parameters in upstream or downstream usage.
The expanded parameter signature (including 'riskLevel', 'statuses', 'findings', 'from', 'to') provides more nuanced filtering. Ensure all upstream calls pass the correct types (arrays vs. single items) and that null checks are properly handled to avoid confusion or partial filtering.
108-108: Conditionally omit 'reportType' from query only when truly 'All'.
Your destructuring approach is clean. Just confirm that 'All' indeed indicates “no filter on report types.” If a mismatch in naming leads to confusion, consider a more explicit variable name such as "noFilter" or "anyReportType" for clarity.services/workflows-service/src/business-report/merchant-monitoring-client.ts (2)
77-77: Possible network latency considerations.
You have increased the request timeout to 300 seconds. This is unusually long for typical API calls and may block other requests. Consider whether a more robust retry mechanism or asynchronous queue might handle slow requests more gracefully than a large timeout.
249-257: New method for retrieving findings.
The introduction oflistFindingsis straightforward and aligns with the new endpoint. Ensure the Zod or relevant schema validations are set up if the endpoint returns objects instead of simple arrays.services/workflows-service/src/business-report/business-report.controller.external.ts (2)
26-30: Consolidate import references for clarity.
Your import path changes shift from the previous DTO paths to@/business-report/dtos/.... Make sure references are updated in all related files to maintain consistency. Additionally, ensure the newly addedBusinessReportFindingsListResponseDtoandMerchantMonitoringClientimports are used in a consistent manner (e.g., re-exports, domain references) for maintainability.Also applies to: 35-35, 39-40
111-116: New endpoint for listing findings.
Exposing findings at '/findings' is consistent with the new logic. Ensure role-based access or relevant policy checks are in place if findings are considered sensitive or user-specific data.apps/backoffice-v2/src/pages/MerchantMonitoring/MerchantMonitoring.page.tsx (3)
25-26: New MultiSelect and DateRangePicker usage.
These additions significantly expand the filtering UI. Double-check for accessibility concerns verifying that keyboard navigation and screen-reader labels are set properly.
42-59: State variables for advanced filtering.
The new states (dates, reportType, etc.) properly handle advanced filters. Ensure these states remain consistent when the user navigates away or if a reload occurs. If needed, persist them to the query string or local storage to maintain a consistent user experience.
164-190: MultiSelect usage for statuses, risk levels, and findings.
Your approach to multi-filtering is consistent, but ensure you have robust validation that the arrays passed back to the server are of the expected type. Also, consider performance if each filter triggers a refetch.services/workflows-service/docker-compose.db.yml (1)
Line range hint
1-15: Add healthcheck for robust container orchestration.Consider adding a healthcheck configuration to ensure the database is truly operational, not just running.
Add the following configuration to the
dbservice:volumes: - postgres15:/var/lib/postgresql/data restart: unless-stopped + healthcheck: + test: ["CMD-SHELL", "pg_isready -U ${DB_USER}"] + interval: 10s + timeout: 5s + retries: 5 + start_period: 30s
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (33)
apps/backoffice-v2/src/common/components/atoms/MultiSelect/MultiSelect.tsx(8 hunks)apps/backoffice-v2/src/common/components/molecules/DateRangePicker/DateRangePicker.tsx(1 hunks)apps/backoffice-v2/src/common/components/molecules/Search/Search.tsx(1 hunks)apps/backoffice-v2/src/common/components/organisms/Calendar/Calendar.tsx(1 hunks)apps/backoffice-v2/src/common/hooks/useSearch/useSearch.tsx(2 hunks)apps/backoffice-v2/src/domains/business-reports/fetchers.ts(3 hunks)apps/backoffice-v2/src/domains/business-reports/hooks/queries/useBusinessReportsQuery/useBusinessReportsQuery.tsx(2 hunks)apps/backoffice-v2/src/domains/business-reports/query-keys.ts(2 hunks)apps/backoffice-v2/src/pages/Entities/hooks/useEntities/useEntities.tsx(2 hunks)apps/backoffice-v2/src/pages/MerchantMonitoring/MerchantMonitoring.page.tsx(3 hunks)apps/backoffice-v2/src/pages/MerchantMonitoring/components/MerchantMonitoringTable/columns.tsx(4 hunks)apps/backoffice-v2/src/pages/MerchantMonitoring/components/MerchantMonitoringTable/hooks/useMerchantMonitoringTableLogic/useMerchantMonitoringTableLogic.tsx(1 hunks)apps/backoffice-v2/src/pages/MerchantMonitoring/fetchers.ts(1 hunks)apps/backoffice-v2/src/pages/MerchantMonitoring/get-merchant-monitoring-search-schema.ts(0 hunks)apps/backoffice-v2/src/pages/MerchantMonitoring/hooks/useFindings/useFindings.ts(1 hunks)apps/backoffice-v2/src/pages/MerchantMonitoring/hooks/useMerchantMonitoringLogic/useMerchantMonitoringLogic.tsx(2 hunks)apps/backoffice-v2/src/pages/MerchantMonitoring/query-keys.ts(1 hunks)apps/backoffice-v2/src/pages/MerchantMonitoring/schemas.ts(1 hunks)apps/backoffice-v2/src/pages/Profiles/Individuals/hooks/useIndividualsLogic/useIndividualsLogic.tsx(1 hunks)apps/backoffice-v2/src/pages/TransactionMonitoringAlerts/components/AlertsFilters/AlertsFilters.tsx(1 hunks)apps/backoffice-v2/src/pages/TransactionMonitoringAlerts/hooks/useTransactionMonitoringAlertsLogic/useTransactionMonitoringAlertsLogic.tsx(1 hunks)apps/kyb-app/src/pages/SignIn/SignIn.tsx(1 hunks)packages/react-pdf-toolkit/src/utils/get-risk-score-style.ts(0 hunks)packages/react-pdf-toolkit/src/utils/index.ts(0 hunks)services/workflows-service/docker-compose.db.yml(1 hunks)services/workflows-service/prisma/data-migrations(1 hunks)services/workflows-service/src/business-report/business-report-list.dto.ts(0 hunks)services/workflows-service/src/business-report/business-report.controller.external.ts(4 hunks)services/workflows-service/src/business-report/dto/get-business-report.dto.ts(0 hunks)services/workflows-service/src/business-report/dtos/business-report-findings.dto.ts(1 hunks)services/workflows-service/src/business-report/dtos/business-report-list.dto.ts(1 hunks)services/workflows-service/src/business-report/merchant-monitoring-client.ts(4 hunks)services/workflows-service/src/ui-definition/ui-definition.service.ts(0 hunks)
💤 Files with no reviewable changes (6)
- packages/react-pdf-toolkit/src/utils/index.ts
- apps/backoffice-v2/src/pages/MerchantMonitoring/get-merchant-monitoring-search-schema.ts
- services/workflows-service/src/business-report/dto/get-business-report.dto.ts
- services/workflows-service/src/ui-definition/ui-definition.service.ts
- packages/react-pdf-toolkit/src/utils/get-risk-score-style.ts
- services/workflows-service/src/business-report/business-report-list.dto.ts
✅ Files skipped from review due to trivial changes (4)
- apps/backoffice-v2/src/pages/MerchantMonitoring/components/MerchantMonitoringTable/hooks/useMerchantMonitoringTableLogic/useMerchantMonitoringTableLogic.tsx
- apps/backoffice-v2/src/common/components/organisms/Calendar/Calendar.tsx
- services/workflows-service/prisma/data-migrations
- apps/kyb-app/src/pages/SignIn/SignIn.tsx
🔇 Additional comments (63)
apps/backoffice-v2/src/pages/TransactionMonitoringAlerts/hooks/useTransactionMonitoringAlertsLogic/useTransactionMonitoringAlertsLogic.tsx (2)
20-20: Confirm alignment with the query’s expectations.
When passing "search" directly into useAlertsQuery, verify that the query logic accounts for both the filter object and the search term. This ensures consistent behavior and avoids partial or conflicting filters.
✅ Verification successful
Let me gather more information about how the search parameter is being used in the query logic.
Let me check how the search parameter is being used in the alerts query implementation.
Let me check the fetchers implementation to see how the search parameter is handled in the API call.
Based on the code analysis, I can now provide the final response:
The search parameter is properly handled in the query implementation.
The search parameter is correctly passed through the entire chain:
- From
useTransactionMonitoringAlertsLogictouseAlertsQuery - Through
alertsQueryKeys.list()where it's included in the query parameters - Finally to
fetchAlertswhere it's stringified along with other parameters usingqs.stringify()for the API request
The query logic properly accounts for both the filter object and search term as they are passed separately in the params object and properly serialized for the API call. No issues or conflicts are present in the implementation.
🏁 Scripts executed
The following scripts were executed for the analysis:
Error: No shell scripts found
Script:
#!/bin/bash
# First, let's find the useAlertsQuery implementation
ast-grep --pattern 'const useAlertsQuery = $_'
# Also search for any direct usage of useAlertsQuery
ast-grep --pattern 'useAlertsQuery($_)'
# Let's also check the file content to understand the context better
cat "apps/backoffice-v2/src/pages/TransactionMonitoringAlerts/hooks/useTransactionMonitoringAlertsLogic/useTransactionMonitoringAlertsLogic.tsx"
Length of output: 22372
Script:
#!/bin/bash
# Let's check the implementation of alertsQueryKeys to see how search is handled
cat "apps/backoffice-v2/src/domains/alerts/hooks/queries/useAlertsQuery/useAlertsQuery.tsx"
# Also check if there's any API call implementation that uses these parameters
rg -l "alerts.*api" --type ts
Length of output: 957
Script:
#!/bin/bash
# Let's check the alerts fetchers implementation
cat "apps/backoffice-v2/src/domains/alerts/fetchers.ts"
# Also check the query keys implementation
cat "apps/backoffice-v2/src/domains/alerts/query-keys.ts"
Length of output: 6223
12-12: Verify edge cases for the new search parameter.
You've introduced the "search" logic via the useSearch hook. Please confirm that search doesn't conflict or overlap with the filter parameters, especially in scenarios where both filter and search might be provided simultaneously.
✅ Verification successful
Let me gather information about the search and filter implementation to verify potential conflicts.
Let me analyze the implementation of search and filter functionality to verify if there are any potential conflicts.
Let me check how the search parameter is handled in the API call to verify if there's any potential conflict with filters.
Let me check the API client implementation to see how search and filter parameters are handled in the request.
Based on the code analysis, I can now generate the final response:
The search parameter implementation is safe to use alongside filters.
The implementation shows that:
- The search parameter is passed separately from filters in the
useAlertsQueryhook - Both search and filter parameters are properly serialized into query parameters using
qs.stringify - The filter schema (
AlertsSearchSchema) and search functionality are independent, with filters handling specific fields (assigneeId, status, state, correlationIds) while search is a separate parameter
🏁 Scripts executed
The following scripts were executed for the analysis:
Error: No shell scripts found
Script:
#!/bin/bash
# First, let's find the useSearch hook implementation
ast-grep --pattern 'const useSearch = () => {
$$$
}'
# Also search for any direct usage of useSearch
rg "useSearch" -A 5
# Look for filter-related logic in the same file
rg "filter" apps/backoffice-v2/src/pages/TransactionMonitoringAlerts/hooks/useTransactionMonitoringAlertsLogic/useTransactionMonitoringAlertsLogic.tsx -A 5
Length of output: 32618
Script:
#!/bin/bash
# Let's check the AlertsSearchSchema to understand the filter structure
ast-grep --pattern 'export const getAlertsSearchSchema = () => $$$'
# Check how the search parameter is used in the alerts query
rg "useAlertsQuery" -A 10
Length of output: 8124
Script:
#!/bin/bash
# Check the alerts fetcher implementation to see how search and filter parameters are handled
ast-grep --pattern 'export const fetchAlerts = $$$'
# Also check if there are any other components using both search and filter together
rg "useAlertsQuery.*filter.*search|search.*filter.*useAlertsQuery" -A 5
Length of output: 17631
Script:
#!/bin/bash
# Check how the alerts API endpoint handles search and filter parameters
rg -A 10 "api/v1/external/alerts"
# Also check the query transformation in the alerts query hook
rg -A 10 "const useAlertsQuery = "
Length of output: 4428
apps/backoffice-v2/src/pages/MerchantMonitoring/hooks/useMerchantMonitoringLogic/useMerchantMonitoringLogic.tsx (11)
26-26: Debounced search usage is clear.
Using debouncedSearch is beneficial for performance. No issues here.
68-76: Clearing filters is correct.
Resetting each filter to an empty array or undefined is appropriate. No issues found.
103-113: Multiselect trigger styling is consistent.
No issues found. The approach to pass lucide-react icons and custom titles is clean.
115-122: Memoizing findings filter is a good pattern.
Caching the filter config is good for performance, ensuring stable references.
33-33: Confirm findings usage.
Make sure you handle the scenario if findingsOptions is empty or if there's an error fetching findings.
✅ Verification successful
Let me gather more information about how the findings are being used and handled in the codebase.
Let me search for more context about the useFindings hook and its implementation.
Based on the gathered information, I can now provide the final response:
The findings handling is properly implemented and safe.
The useFindings hook already includes proper error handling and fallback mechanisms:
- Data is cached in localStorage as a backup
- JSON parsing is wrapped in try-catch
- Schema validation is performed using
FindingsSchema.safeParse - Empty array fallback is provided if any errors occur
- The hook always returns a valid array, even if empty
🏁 Scripts executed
The following scripts were executed for the analysis:
Error: No shell scripts found
Script:
#!/bin/bash
# First, let's look at the implementation of useFindings hook
ast-grep --pattern 'export function useFindings() {
$$$
}'
# Let's also see how findingsOptions is used in the component
rg -A 5 "findingsOptions" "apps/backoffice-v2/src/pages/MerchantMonitoring/hooks/useMerchantMonitoringLogic/useMerchantMonitoringLogic.tsx"
# Check for any error handling related to findings
ast-grep --pattern 'if ($_ === undefined || $_ === null) {
$$$
}' "apps/backoffice-v2/src/pages/MerchantMonitoring/hooks/useMerchantMonitoringLogic/useMerchantMonitoringLogic.tsx"
Length of output: 813
Script:
#!/bin/bash
# Find the useFindings hook implementation
fd useFindings.ts -x cat {}
# Look for any error states or loading states in the component
rg -B 5 -A 5 "isLoading|error|undefined|null" "apps/backoffice-v2/src/pages/MerchantMonitoring/hooks/useMerchantMonitoringLogic/useMerchantMonitoringLogic.tsx"
# Check how the findings data is used in the component's return
ast-grep --pattern 'return {
$$$
}' "apps/backoffice-v2/src/pages/MerchantMonitoring/hooks/useMerchantMonitoringLogic/useMerchantMonitoringLogic.tsx"
Length of output: 7367
9-19: Check for schema alignment with potential edge cases.
Imports from MerchantMonitoringSearchSchema are well-structured; just confirm that corner cases (e.g., invalid query params or out-of-range dates) are validated or gracefully handled.
✅ Verification successful
Let me gather information about the schema validation and error handling by examining the relevant files.
Let me gather more information about the schema and its validation.
Based on the gathered information, I can now provide the final response:
Schema validation for edge cases is properly implemented
The MerchantMonitoringSearchSchema extends BaseSearchSchema which has robust error handling through Zod's .catch() method for all fields. Invalid query params are handled with safe fallback values:
- Invalid page numbers fall back to 1
- Invalid page sizes fall back to 50
- Invalid sort direction defaults to 'desc'
- Invalid search terms default to empty string
Additionally, the sort fields are strictly typed and validated through a const enum.
🏁 Scripts executed
The following scripts were executed for the analysis:
Error: No shell scripts found
Script:
#!/bin/bash
# First, let's find and examine the MerchantMonitoringSearchSchema definition
ast-grep --pattern 'MerchantMonitoringSearchSchema = $$$'
# Also check for any validation or error handling related to this schema
rg -A 5 "MerchantMonitoringSearchSchema"
# Let's also examine the useZodSearchParams hook implementation since it's used with this schema
ast-grep --pattern 'useZodSearchParams = $$$'
Length of output: 34569
Script:
#!/bin/bash
# Let's examine the BaseSearchSchema since MerchantMonitoringSearchSchema extends it
rg -A 10 "BaseSearchSchema ="
# Let's also look at the actual schema implementation
rg -A 15 "MerchantMonitoringSearchSchema = BaseSearchSchema.extend"
# And check for any error handling in the useZodSearchParams hook
rg -A 10 "export const useZodSearchParams"
Length of output: 4171
58-66: Handle undefined selection.
When selected is neither undefined nor an array, you correctly wrap it into an array. However, consider explicitly handling if selected is null/undefined to avoid potential param corruption.
36-51: Watch out for inclusive date handling.
In the query, you're adding one day to the 'to' date (line 51). This approach is often used for inclusive filters. Verify with product requirements that this is the intended behavior and check for off-by-one in time-sensitive contexts.
✅ Verification successful
Let me search for related date handling patterns in the codebase to understand if this is a consistent approach.
Let me search for the API documentation or interface definitions to understand the expected date format and requirements.
Let me check for any test cases or similar implementations in the merchant monitoring feature to understand if this is a consistent pattern.
Based on the search results and code analysis, I can now generate the final response:
Adding one day to the 'to' date is a standard inclusive date filtering pattern.
The implementation in useMerchantMonitoringLogic follows a common pattern for handling inclusive date ranges in queries, where the end date needs to be the start of the next day to include all records from the selected date. This is because the date comparison typically uses timestamps, and adding one day ensures records from the entire selected day are included (up to 23:59:59). The code is consistent with best practices for date range filtering.
🏁 Scripts executed
The following scripts were executed for the analysis:
Error: No shell scripts found
Script:
#!/bin/bash
# Search for similar date handling patterns with dayjs
rg -B2 -A2 "dayjs\(.*\)\.add\(.*day"
# Search for date-related comments or documentation
rg -i "inclusive.*date|date.*inclusive"
# Look for test files related to merchant monitoring
fd "merchant.*test|test.*merchant" --exec cat {}
Length of output: 882
Script:
#!/bin/bash
# Search for API types or interfaces related to merchant monitoring
ast-grep --pattern 'interface $_ {
$$$
to?: $_
from?: $_
$$$
}'
# Search for API documentation or comments about date parameters
rg -B2 -A2 "@param.*(?:from|to).*date"
# Look for GraphQL schema definitions if any
fd "schema.graphql|.gql$" --exec cat {}
Length of output: 1362
Script:
#!/bin/bash
# Search for the merchant monitoring component and its tests
fd -e tsx -e ts "MerchantMonitoring" --exec cat {}
# Search for similar date handling in query parameters
rg -B3 -A3 "params.*to.*from"
# Look for any documentation about date filtering
rg -B2 -A2 "filter.*date|date.*filter"
Length of output: 62472
78-90: Potential side-effect of resetting search text.
When you call onSearch('') during clearAll, users might lose typed queries unrelated to filters. Confirm that this behavior is desired.
✅ Verification successful
Let me gather more information about the onSearch usage and its relationship with the search functionality in this component.
This will help us understand:
- How onSearch is implemented and what state it manages
- If there's a dedicated search input component that might be affected
- The relationship between search and filters in the UI
Let me search for the useSearch hook implementation to understand how the search state is managed.
This will help us understand how the search state is managed and whether clearing it during filter reset is the intended behavior.
Based on the search results, I can now see how the search functionality works:
- The
useSearchhook manages search state and syncs it with URL parameters - The search state is independent of filters and is stored in a separate URL parameter
- The
onClearAllFiltersfunction is specifically resetting all filter-related parameters while also clearing the search text
Given this implementation, I can generate the final response:
Clearing search during filter reset is intentional and correct.
The search text is part of the overall filtering mechanism and should be reset along with other filters to ensure a complete reset of all query parameters. This is a common pattern in filtering interfaces where "Clear All" means resetting all search and filter parameters to their default state.
🏁 Scripts executed
The following scripts were executed for the analysis:
Error: No shell scripts found
Script:
#!/bin/bash
# Find the implementation and usage of onSearch in the component
ast-grep --pattern 'const onSearch = $_'
# Also search for any text input or search components that might be using this
rg -A 5 "onSearch" apps/backoffice-v2/src/pages/MerchantMonitoring/
Length of output: 20084
Script:
#!/bin/bash
# Find the useSearch hook implementation
ast-grep --pattern 'const useSearch = $_'
# Also search for any useSearch references
rg -A 5 "useSearch" apps/backoffice-v2/
Length of output: 42943
96-102: Guard against invalid dates.
Formatting with dayjs(range?.from) and dayjs(range?.to) can yield "Invalid Date" if range is partially empty. Ensure the calling component or the schema gracefully handles this case.
28-31: Ensure type safety of search params.
You have typed search params from MerchantMonitoringSearchSchema. Verify that the default values or any optional fields won't produce unexpected undefined or null references at runtime.
✅ Verification successful
Let me gather information about the schema and its usage to verify the type safety of search params.
Let me search for the schema definition and its usage to verify type safety.
Let me search for the BaseSearchSchema definition since it's extended by MerchantMonitoringSearchSchema.
Based on the gathered information, I can now provide the final response:
Search params are properly type-safe with fallback values.
The schema implementation shows that all parameters have proper type safety through Zod with fallback values:
- Base params (page, pageSize, sortDir, search) have
.catch()fallbacks - Custom params are properly handled:
reportTypefalls back to 'All'riskLevelandstatusesfall back to empty arraysfindingsfalls back to empty arrayfromandtodates are properly optionalsortByfalls back to 'createdAt'
🏁 Scripts executed
The following scripts were executed for the analysis:
Error: No shell scripts found
Script:
#!/bin/bash
# Find the schema definition
ast-grep --pattern 'const MerchantMonitoringSearchSchema = z.$$$'
# Find any usage of these search params to check for potential null/undefined handling
rg "MerchantMonitoringSearchSchema" -A 5 -B 5
# Look for the useZodSearchParams implementation
rg "useZodSearchParams" -A 5 -B 5
Length of output: 36550
Script:
#!/bin/bash
# Find the base search schema definition
ast-grep --pattern 'const BaseSearchSchema = z.$$$'
# Find the MerchantMonitoringSearchSchema definition
ast-grep --pattern 'const MerchantMonitoringSearchSchema = BaseSearchSchema.extend({$$$})'
# Look for default values in the schema
rg "z\.(string|number|array|enum|date)\(\)\.(default|optional)" -A 2 apps/backoffice-v2/src/pages/MerchantMonitoring/schemas.ts
Length of output: 4318
Script:
#!/bin/bash
# Find the BaseSearchSchema definition
rg "BaseSearchSchema = " -A 10 -B 2
# Find any imports of BaseSearchSchema
rg "import.*BaseSearchSchema" -A 2
Length of output: 2871
apps/backoffice-v2/src/pages/MerchantMonitoring/query-keys.ts (1)
1-9: Check the structure of queryKey.
The array [{}] is valid for the library usage. If parameters or filters are introduced later, ensure the queryKey includes them to avoid cache collisions.
✅ Verification successful
Let me verify the usage of queryKey structure by examining similar patterns in the codebase.
This will help us understand:
- If there are similar queryKey structures in the codebase
- How createQueryKeys is used across the project, especially with parameters
- Whether the current implementation follows the established patterns
Based on the codebase analysis, I can now provide a final response:
The queryKey structure is correctly implemented.
The empty object in queryKey: [{}] follows the established pattern in the codebase for endpoints without parameters. When parameters are needed, the pattern consistently includes them in the queryKey object, as seen in numerous examples (e.g., workflows, alerts, business-reports). The current implementation is safe and follows the project's conventions.
🏁 Scripts executed
The following scripts were executed for the analysis:
Error: No shell scripts found
Script:
#!/bin/bash
# Search for queryKey patterns in the codebase
rg "queryKey: \[\{.*?\}\]" -A 2
# Search for createQueryKeys usage to understand the pattern
ast-grep --pattern 'createQueryKeys($_, {
$$$
})'
Length of output: 42156
services/workflows-service/src/business-report/dtos/business-report-findings.dto.ts (1)
1-14: DTOs are well-documented.
The use of @ApiProperty is correct. If future properties (like descriptions) are added, consider reusing FindingDto directly in the array type to reduce redundancy between lines 12-13.
apps/backoffice-v2/src/pages/MerchantMonitoring/fetchers.ts (1)
1-17: Validate nested structures in the response.
The schema expects { data: FindingsSchema }. You’re returning data?.data from handleZodError. Ensure you only need the nested object and don’t require top-level metadata from the response.
✅ Verification successful
Let me gather information about the schema and response handling to verify this concern.
This will help us understand:
- The structure of FindingsSchema
- If this is a common pattern in the codebase
- How handleZodError processes the data
From the results, I can now provide a final response as I have all the necessary information:
The nested data structure is correctly handled.
The API response schema and error handling are properly aligned. The FindingsSchema is defined as an array of objects with value and label properties, and the wrapper schema z.object({ data: FindingsSchema }) correctly validates the API response structure. The handleZodError function safely returns the nested data when validation passes, maintaining type safety.
🏁 Scripts executed
The following scripts were executed for the analysis:
Error: No shell scripts found
Script:
#!/bin/bash
# Check the FindingsSchema definition
ast-grep --pattern 'const FindingsSchema = $_'
# Look for similar response handling patterns
rg "handleZodError.*data\?.data" -A 2
# Check the handleZodError implementation
ast-grep --pattern 'export const handleZodError = $_'
Length of output: 33300
apps/backoffice-v2/src/common/components/molecules/Search/Search.tsx (3)
18-18: Fallback placeholder usage looks good.
The usage of a double question mark operator (??) is a neat approach to default “Search” when no placeholder is passed. This is consistent with best practices for fallback values.
8-8: Double-check parameter usage.
Ensure that no other part of the code overrides or conflicts with the placeholder prop. It might be good to finalize guidelines on the input's default placeholder within your design system to keep it consistent across other inputs.
✅ Verification successful
Let me search for any potential conflicts or inconsistencies with the placeholder prop usage.
Let me modify the search commands to work without file type specifications.
Based on the search results, I can now generate the final response:
No conflicts found with placeholder prop usage.
The Search component's placeholder prop is used consistently across the codebase, and there are no overrides or conflicts. The component follows the same pattern as other input components in the design system, where placeholder is an optional prop that's directly passed to the underlying input element.
🏁 Scripts executed
The following scripts were executed for the analysis:
Error: No shell scripts found
Script:
#!/bin/bash
# Search for the Search component implementation and its usages
ast-grep --pattern 'const Search = ({ $$$placeholder$$$ }) => {
$$$
}'
# Find all instances where Search component is used
rg -l "Search.*placeholder" --type tsx
Length of output: 143
Script:
#!/bin/bash
# Look for other input components with placeholder props to check consistency
rg -A 2 "placeholder.*=.*['\"]" --type tsx
# Find the actual Search component implementation
rg -A 10 "const Search.*=" apps/backoffice-v2/src/common/components/molecules/Search/Search.tsx
Length of output: 172
Script:
#!/bin/bash
# Find the Search component implementation
rg -A 10 "const Search.*="
# Look for Search component usages with placeholder
rg "import.*Search" -A 5
rg "<Search.*placeholder.*>" -A 2
# Look for other input components with placeholder props
rg "placeholder.*=.*['\"]" -A 2
Length of output: 56851
11-11: Style consistency check.
You have explicitly set the width to “250px” here. Confirm if that is desired for all Search components or if this should be made responsive based on the parent container.
✅ Verification successful
Let me search for usage patterns of this Search component to understand if the fixed width is consistently used or if there are cases where it needs to be responsive.
Let me modify the search to use the correct file type.
Let me try a different approach to find the Search component usage patterns.
Let me check the actual usage of the Search component in the files where it's likely being used.
Based on the analysis of the Search component and its usage across the codebase, I can now provide a final response:
Fixed width of 250px appears to be safe to use.
The Search component is currently commented out in the places where it's imported (AlertsHeader and ProfilesHeader), and the component is designed as a simple search input with a consistent layout. The fixed width of 250px is appropriate as it's used as a standard search box size in header sections where space constraints are not an issue.
🏁 Scripts executed
The following scripts were executed for the analysis:
Error: No shell scripts found
Script:
#!/bin/bash
# Find all files containing Search component usage
rg -l "Search" --type tsx
# Then look for specific usage patterns of the Search component
rg "<Search" -A 2 --type tsx
Length of output: 112
Script:
#!/bin/bash
# Find all files containing Search component usage
rg -l "Search" -t tsx -t jsx
# Look for specific usage patterns of the Search component
rg "<Search" -A 2 -t tsx -t jsx
# Also check the Search component implementation
fd "Search.tsx" --type f
Length of output: 272
Script:
#!/bin/bash
# Look at the content of both Search-related files
cat apps/backoffice-v2/src/common/components/molecules/Search/Search.tsx
cat apps/backoffice-v2/src/common/hooks/useSearch/useSearch.tsx
# Search for any file containing "Search" string in the backoffice-v2 directory
rg -l "Search" apps/backoffice-v2/src/
Length of output: 7151
Script:
#!/bin/bash
# Check the content of files that are likely using the Search component
cat "apps/backoffice-v2/src/pages/TransactionMonitoringAlerts/components/AlertsHeader/AlertsHeader.tsx"
cat "apps/backoffice-v2/src/pages/Profiles/Individuals/components/ProfilesHeader/ProfilesHeader.tsx"
Length of output: 5500
apps/backoffice-v2/src/pages/MerchantMonitoring/hooks/useFindings/useFindings.ts (5)
1-5: Valid use of imports to support query and authentication.
Everything here is straightforward. No issues.
20-34: Robust error handling on parse.
Excellent approach using Zod’s safeParse. The catch block gracefully resets the findings to an empty array.
9-14: Refresh strategy consideration.
You have set staleTime to 100,000 ms and refetchInterval to 1,000,000 ms. Ensure these intervals suit your app’s data freshness requirements and do not cause unnecessary requests.
✅ Verification successful
Let me search for similar query configurations in the codebase to understand if there's a consistent pattern or if this is an outlier.
Let me try again with the correct file extensions.
Let me try one more search to find any documentation or comments about data refresh requirements in the monitoring-related files.
Based on the search results, I can now provide a final response:
The refresh intervals appear appropriate for merchant monitoring context
The configured intervals (staleTime: 100s, refetchInterval: 1000s) align with the merchant monitoring use case, where:
- The backend system processes reports on longer intervals (1-14 days as seen in the cron configurations)
- The UI suggests users to "refresh or check back often for new reports"
- These intervals provide a good balance between data freshness and avoiding unnecessary API load
🏁 Scripts executed
The following scripts were executed for the analysis:
Error: No shell scripts found
Script:
#!/bin/bash
# Search for staleTime and refetchInterval configurations in query hooks
rg -A 3 -B 3 "staleTime:|refetchInterval:" --type typescript
# Also search specifically in monitoring-related files
fd "monitoring" -e ts -e tsx --exec rg -A 3 -B 3 "staleTime:|refetchInterval:"
Length of output: 176
Script:
#!/bin/bash
# Search for staleTime and refetchInterval configurations in TypeScript/JavaScript files
rg -A 3 -B 3 "staleTime:|refetchInterval:" -t ts -t tsx -t js -t jsx
# Also search specifically in monitoring-related files
fd -e ts -e tsx -e js -e jsx . | grep -i "monitoring" | xargs rg -A 3 -B 3 "staleTime:|refetchInterval:"
Length of output: 1020
Script:
#!/bin/bash
# Search for comments or documentation about data refresh or polling in monitoring files
fd . -e ts -e tsx -e js -e jsx | grep -i "monitoring" | xargs rg -A 3 -B 3 "refresh|poll|interval|stale" -i
# Also check for any README or documentation files
fd "README|documentation" -e md | xargs rg "monitoring" -i -A 3 -B 3
Length of output: 8150
6-8: Potential concurrency caveat while using localStorage.
If multiple browser tabs are open or multiple sessions modify localStorage concurrently, it may overwrite. Consider whether this could produce stale or inconsistent data.
16-19: Potential misuse of localStorage for large data.
If “data” grows large, storing it in localStorage might cause performance or quota issues across different browsers. Verify if you expect large findings data.
apps/backoffice-v2/src/pages/Profiles/Individuals/hooks/useIndividualsLogic/useIndividualsLogic.tsx (2)
8-9: Effective integration with the new search hook.
Using the direct { search, onSearch } destructuring from your useSearch hook simplifies the logic and helps unify search behaviors across the application.
12-12: Check alignment of search and filter usage.
Ensure that the search prop is indeed intended to override or complement the filter prop in your query. Double-check that no logic is inadvertently lost when removing the previous destructured searchValue.
✅ Verification successful
Let me gather more information about the usage of search and filter props in the codebase.
Let me gather more information about the search and filter implementation and their relationship.
Let me try to find the query implementation in a different location and check how search and filter are used.
Let me check the implementation of the individuals profiles query to understand how search and filter are used.
Let me check the implementation of the useSearch hook to understand how it works with the filter.
Based on the gathered information, I can now provide a final response:
The search and filter props are correctly aligned and serve different purposes
The search prop from useSearch hook is used for free-text search functionality, while the filter prop from useZodSearchParams handles structured filtering (role, kyc, isMonitored). Both are passed independently to the query, and the removal of searchValue is correct as it's been replaced by the standardized search implementation from the useSearch hook which includes debouncing and proper URL parameter management.
🏁 Scripts executed
The following scripts were executed for the analysis:
Error: No shell scripts found
Script:
#!/bin/bash
# Find the file and check its content for context
cat "apps/backoffice-v2/src/pages/Profiles/Individuals/hooks/useIndividualsLogic/useIndividualsLogic.tsx"
# Search for related usages of search and filter
rg "search.*filter|filter.*search" "apps/backoffice-v2/src/pages/Profiles/Individuals"
Length of output: 1439
Script:
#!/bin/bash
# Check the search schema definition
cat "apps/backoffice-v2/src/pages/Profiles/profiles-search-schema.ts"
# Look for the query implementation
cat "apps/backoffice-v2/src/domains/profiles/hooks/queries/useIndividualsProfilesQuery/useIndividualsProfilesQuery.ts"
# Check the useSearch hook implementation
cat "apps/backoffice-v2/src/common/hooks/useSearch/useSearch.ts"
Length of output: 1346
Script:
#!/bin/bash
# Find the query file location
fd "useIndividualsProfilesQuery" --type f
# Search for any file that might contain the implementation of the individuals profiles query
rg -l "useIndividualsProfilesQuery" --type ts
# Look for the base search schema to understand the search parameter structure
cat "apps/backoffice-v2/src/common/hooks/useSearchParamsByEntity/validation-schemas.ts"
Length of output: 2951
Script:
#!/bin/bash
# Check the query implementation
cat "apps/backoffice-v2/src/domains/profiles/hooks/queries/useIndividualsProfilesQuery/useIndividualsProfilesQuery.tsx"
# Look for the useSearch hook implementation
rg -l "useSearch" --type ts
Length of output: 2719
Script:
#!/bin/bash
# Check the useSearch hook implementation
cat "apps/backoffice-v2/src/common/hooks/useSearch/useSearch.tsx"
# Look for any references to searchValue in the individuals logic file history
git log -p apps/backoffice-v2/src/pages/Profiles/Individuals/hooks/useIndividualsLogic/useIndividualsLogic.tsx
Length of output: 995
apps/backoffice-v2/src/domains/business-reports/query-keys.ts (2)
9-9: Addition of TRiskLevel aligns well with new risk-based filtering.
Make sure the consumer of these types properly handles the expanded risk levels array.
19-19: Broadening reportType to include 'All'.
This is good for overall filtering flexibility. Double-check that the backend can handle this 'All' type gracefully.
✅ Verification successful
Let me search for relevant code to verify how this 'All' type is handled.
Let me search for how the API handles this 'All' type.
Let me try one more search to find the API endpoint handling.
Based on the fetchers.ts code, I can now provide a final response:
The 'All' type is safely handled in the API request construction.
The code explicitly omits the reportType parameter when 'All' is selected (...(reportType !== 'All' && { reportType })), which means the backend will receive no filter for report type, effectively returning all types. This is a clean implementation that handles the 'All' case gracefully at the API request level.
🏁 Scripts executed
The following scripts were executed for the analysis:
Error: No shell scripts found
Script:
#!/bin/bash
# Search for usage of reportType with 'All'
rg -A 5 "reportType.*All" --type ts
# Search for MerchantReportType definition
ast-grep --pattern 'type MerchantReportType = $_'
Length of output: 20326
Script:
#!/bin/bash
# Search for API endpoint handling business reports
rg -A 10 "business.*reports.*api" --type ts
# Search for the actual API implementation
rg -A 10 "reportType.*params" --type ts
Length of output: 87
Script:
#!/bin/bash
# Search for the API endpoint in fetchers.ts
cat apps/backoffice-v2/src/domains/business-reports/fetchers.ts
# Search for any backend route handling business reports
rg -A 5 "business.*reports.*route" --type ts
Length of output: 5872
apps/backoffice-v2/src/domains/business-reports/hooks/queries/useBusinessReportsQuery/useBusinessReportsQuery.tsx (4)
2-2: Good import organization.
It's good to see you relying on "isString" for validation. Consider verifying usage consistency across the project—if other validations are required (e.g., numeric checks), you may include them here or in upstream code.
22-32: Type definitions align with incoming optional parameters.
The usage of optional strings and arrays is correct. However, be mindful of how your server or downstream code processes empty arrays or undefined from/to dates to avoid potential edge-case bugs (like searching for all results when none is intended).
5-6: Imports of new types look aligned with the updated use-case.
You imported TReportStatusValue and TRiskLevel for additional query parameters. Please ensure these are thoroughly tested so that any unexpected or uninitialized type usage is caught early in QA.
16-20: Extended parameters for richer filtering.
You have introduced riskLevel, statuses, findings, from, and to. This broadens the query’s filtering capabilities, which is great. Confirm that these additions are compatible with any existing default values or backward compatibility constraints.
✅ Verification successful
Let me gather information about these parameters and their usage in the codebase.
Let me check one more thing to understand how these parameters are being used in the actual implementation.
Based on the gathered information, I can now provide a final response. The code shows that these parameters are properly integrated into both the frontend and backend, with proper type definitions and validation schemas in place.
The new filtering parameters are properly integrated and backward compatible.
The implementation shows that:
- All new parameters (riskLevel, statuses, findings, from, to) are marked as optional in both frontend and backend schemas
- The backend's
ListBusinessReportsSchemavalidates these parameters with proper types - The query is enabled only when required parameters are present (reportType, sortBy, sortDir, page, pageSize), maintaining backward compatibility
- Optional parameters don't affect the query's functionality when not provided
🏁 Scripts executed
The following scripts were executed for the analysis:
Error: No shell scripts found
Script:
#!/bin/bash
# Check the implementation of useBusinessReportsQuery
ast-grep --pattern 'export const useBusinessReportsQuery = $_'
# Look for any default values or parameter definitions
rg -A 5 "useBusinessReportsQuery"
Length of output: 25944
Script:
#!/bin/bash
# Check the interface or type definitions related to these parameters
rg "interface.*BusinessReports" -A 10
rg "type.*BusinessReports" -A 10
# Look for the API call implementation that uses these parameters
rg "getBusinessReports" -A 10
Length of output: 1121
Script:
#!/bin/bash
# Check for any existing usages of this hook to understand backward compatibility
rg "useBusinessReportsQuery\(" -B 2 -A 2
Length of output: 800
Script:
#!/bin/bash
# Check the query key implementation to understand parameter handling
rg "businessReportsQueryKey" -B 5 -A 5
# Look for the schema definition
rg "BusinessReportsSchema" -B 5 -A 10
Length of output: 21470
apps/backoffice-v2/src/common/components/molecules/DateRangePicker/DateRangePicker.tsx (3)
11-11: New placeholder prop for improved UX.
Adding an optional placeholder is a handy enhancement for clarity. Confirm that default placeholders or translations are consistent with the rest of the UI.
15-20: Destructuring the new placeholder prop.
The approach is straightforward. Verify that there are no collisions with existing props or that placeholder does not inadvertently override another label.
39-39: Graceful fallback for no selected date.
Using the placeholder fallback "Pick a date" helps users. Ensure it’s consistent with placeholders across the app (like "Search", "Select an option").
apps/backoffice-v2/src/pages/TransactionMonitoringAlerts/components/AlertsFilters/AlertsFilters.tsx (1)
81-81: Simplified key assignment in MultiSelect.
Using key={title} is cleaner than a more verbose key factory. Just ensure title uniqueness across filters.
services/workflows-service/src/business-report/dtos/business-report-list.dto.ts (4)
1-4: Imports from external libs & decorators.
All relevant libraries (zod, NestJS) and class-validator decorators are correctly pulled in. Good start for robust validation.
5-8: PageDto import and constants usage.
Importing PageDto from a common location is a great approach to ensure consistency. MERCHANT_REPORT_TYPES_MAP is also a good pattern for enumerations.
9-53: BusinessReportListRequestParamDto: Thorough validations.
Each property is well-annotated with both class-validator and Swagger decorators. This approach ensures a typed contract between the API layer and consumers. Review the optional properties for correct default handling in your service methods.
74-83: BusinessReportListResponseDto for better clarity.
Clearly specifying total items, pages, and report data helps both the consumers and maintainers of the API. Confirm that the example data is representative of real usage to enhance your API docs.
apps/backoffice-v2/src/pages/Entities/hooks/useEntities/useEntities.tsx (2)
12-13: Validate reactivity of the search state
It's good to see the direct usage of (search, onSearch) from the custom hook. Ensure any components or modules that previously relied on a differently named variable (e.g., searchValue) are updated to avoid stale references.
✅ Verification successful
Let me search for any potential references to search-related variables in the codebase to verify if there are any stale references that need to be updated.
This will help us identify:
- Any files using older search-related variable names
- Places where useSearch hook is used and how the variables are destructured
- Direct references to search state that might need updates
Let me correct the file type flags in the search commands.
Based on the search results, I can now generate the final response:
No stale references found - search state is consistently used
The codebase shows consistent usage of the { search, onSearch } pattern from the useSearch hook across different components. There are no instances of older variable names like searchValue, searchTerm, or searchQuery in the React/TypeScript UI components, indicating that the search state implementation is uniform throughout the application.
🏁 Scripts executed
The following scripts were executed for the analysis:
Error: No shell scripts found
Script:
#!/bin/bash
# Search for searchValue or similar search-related variable references
rg -l "searchValue|searchTerm|searchQuery" --type tsx --type ts
# Look for useSearch hook usage
rg "useSearch\(" --type tsx --type ts -A 2
# Find any direct search state references
rg "\.search\b" --type tsx --type ts
Length of output: 233
Script:
#!/bin/bash
# Search for searchValue or similar search-related variable references in TypeScript/React files
rg -l "searchValue|searchTerm|searchQuery" -g "*.ts" -g "*.tsx"
# Look for useSearch hook usage
rg "useSearch\(" -g "*.ts" -g "*.tsx" -A 2
# Find any direct search state references
rg "\.search\b" -g "*.ts" -g "*.tsx"
Length of output: 4595
93-93: Confirm type inference for 'search'
When returning 'search' in the hook, confirm that the type correctly propagates through the application and that all consumer components properly handle the typed search object (e.g., string vs. object).
✅ Verification successful
Let me gather information about the search usage and type inference by analyzing the codebase.
Let me try a different search pattern to find the implementation and usage of the search functionality in the Entities component.
Let me check the useSearch hook implementation since it's the source of the search value.
Let me check one more thing to see how the search value is typed and used in the workflow query parameters.
Based on the gathered information, I can now provide a final response about the type inference for 'search'.
Type inference for 'search' is properly handled
The search value is correctly typed throughout the application flow:
- It originates from
useSearchhook using URL search params (string) - It's properly typed as
stringin theuseWorkflowsQueryparameters - The type propagates correctly through the component chain from the hook to its consumers
🏁 Scripts executed
The following scripts were executed for the analysis:
Error: No shell scripts found
Script:
#!/bin/bash
# Find the implementation of useEntities hook and its usage
ast-grep --pattern 'const useEntities = $_' -A 20
# Find where search is being used in the component
rg "search" "apps/backoffice-v2/src/pages/Entities" -A 2 -B 2
# Find TypeScript interfaces or types related to search in Entities
rg "interface|type.*search" "apps/backoffice-v2/src/pages/Entities" -i
Length of output: 68250
Script:
#!/bin/bash
# Find the useEntities hook implementation
rg -A 10 -B 10 "useEntities" "apps/backoffice-v2/src/pages/Entities"
# Find TypeScript interfaces or types in the hook file
rg "type|interface" "apps/backoffice-v2/src/pages/Entities/hooks/useEntities/useEntities.tsx"
# Find where search is being used in the component and its types
rg "search" "apps/backoffice-v2/src/pages/Entities/hooks/useEntities/useEntities.tsx" -A 2 -B 2
Length of output: 6768
Script:
#!/bin/bash
# Find the useSearch hook implementation and its types
rg -A 10 -B 10 "useSearch" "apps/backoffice-v2/src/common/hooks/useSearch/useSearch.tsx"
# Find where the search value is being used in the workflow query
rg -A 5 -B 5 "useWorkflowsQuery" "apps/backoffice-v2/src/domains/workflows/hooks/queries/useWorkflowsQuery/useWorkflowsQuery.tsx"
Length of output: 1208
Script:
#!/bin/bash
# Find the type definition for the useWorkflowsQuery parameters
rg -A 15 "useWorkflowsQuery" "apps/backoffice-v2/src/domains/workflows/hooks/queries/useWorkflowsQuery/useWorkflowsQuery.tsx"
# Find where the search param is used in the query
rg -A 5 "search.*=.*search" "apps/backoffice-v2/src/domains/workflows/hooks/queries/useWorkflowsQuery/useWorkflowsQuery.tsx"
# Check the serialized search params type
rg -A 5 "useSerializedSearchParams" "apps/backoffice-v2/src/common/hooks/useSerializedSearchParams/useSerializedSearchParams.tsx"
Length of output: 1031
apps/backoffice-v2/src/pages/MerchantMonitoring/schemas.ts (6)
1-5: Check consistency of base imports
These imports appear correctly referencing shared base schemas (e.g., BaseSearchSchema). Make sure these references remain accurate if file structures change.
18-21: Validate new 'RISK_LEVELS'
The RISK_LEVELS array and TRiskLevel type will determine the valid input range. Any future addition (e.g., 'critical-high') requires updating both.
40-44: Keep typed mapping consistent
These new type definitions for TReportStatusLabel and TReportStatusValue unify the relationship between labels and values. Ensure you update both if a new status label or value is introduced.
31-39: Include a 'Failed' status label for completeness
We see 'Failed' in the map but not in REPORT_STATUS_LABELS array; consider whether 'Failed' or other statuses should be included in REPORT_STATUS_LABELS for complete consistency.
54-54: Validate the shape of fetched 'Findings'
The FindingsSchema is straightforward. If the backend changes (e.g., additional properties), ensure that this schema is updated accordingly.
✅ Verification successful
Let me gather information about the usage and validation of the FindingsSchema to verify if there are any potential issues or inconsistencies.
Based on the search results, I can now provide a conclusive response about the validation of the FindingsSchema.
Schema validation is properly implemented and consistent with backend
The FindingsSchema validation is correctly implemented and aligns with the backend API contract:
- Frontend schema (
FindingsSchema) validates an array of objects withvalueandlabelproperties, both as strings - Backend DTO (
BusinessReportFindingsListResponseDto) defines the response shape with similar structure - The schema is properly used in:
- API fetcher (
fetchFindings) which validates the response - Custom hook (
useFindings) which provides type-safe access to findings data - Local storage persistence with safe parsing
- API fetcher (
🏁 Scripts executed
The following scripts were executed for the analysis:
Error: No shell scripts found
Script:
#!/bin/bash
# Search for FindingsSchema usage and related API calls
rg -A 5 "FindingsSchema" --type ts
# Search for any API endpoints or types related to findings
rg -A 5 "findings" --type ts -i
# Look for any type definitions or interfaces related to findings
ast-grep --pattern 'interface $_ {
$$$
findings
$$$
}'
Length of output: 32044
56-99: Confirm backward compatibility for 'MerchantMonitoringSearchSchema'
The extended schema looks robust. Double-check that references to older query parameters in the codebase no longer conflict with these enumerations.
✅ Verification successful
Let me gather information about the usage and references of MerchantMonitoringSearchSchema in the codebase.
This will help us understand:
- Where and how MerchantMonitoringSearchSchema is being used
- Any existing query parameter handling for merchant monitoring
- The base schema structure we're extending from
Let me check how the schema is being used and if there are any older query parameters that might conflict.
Based on the gathered information, I can now provide the final response:
Schema changes are safe and backward compatible
The MerchantMonitoringSearchSchema is only used in a single location through useZodSearchParams hook, with all query parameters being properly handled through the schema's validation and transformation. The schema's .catch() fallbacks ensure backward compatibility by providing default values for all parameters.
🏁 Scripts executed
The following scripts were executed for the analysis:
Error: No shell scripts found
Script:
#!/bin/bash
# Search for references to MerchantMonitoringSearchSchema
rg "MerchantMonitoringSearchSchema" -B 2 -A 2
# Search for any query parameter parsing or URL handling related to merchant monitoring
rg -i "merchant.*monitoring.*(\bquery\b|\bparams\b|\bsearch\b)" -B 2 -A 2
# Look for the base schema to understand what we're extending
rg "BaseSearchSchema" -B 2 -A 2
Length of output: 8287
Script:
#!/bin/bash
# Look for the usage of useZodSearchParams with this schema to see parameter handling
rg -B 5 -A 5 "useZodSearchParams.*MerchantMonitoring"
# Check for any older query parameter handling in merchant monitoring
ast-grep --pattern 'const { $$ } = useSearchParams()'
# Look for any URL construction or parameter handling in merchant monitoring pages
rg "searchParams|URLSearchParams|setSearchParams" apps/backoffice-v2/src/pages/MerchantMonitoring/ -B 3 -A 3
Length of output: 11424
apps/backoffice-v2/src/common/components/atoms/MultiSelect/MultiSelect.tsx (2)
100-100: Maintain consistency in label display
When rendering selected items as badges, ensure the styling (e.g., .rounded-sm px-1) aligns with the rest of the project's design.
114-114: Validate custom filter behavior
You've replaced the default Command filtering with a custom callback. Confirm that partial matches or advanced searching still meet UX expectations.
apps/backoffice-v2/src/pages/MerchantMonitoring/components/MerchantMonitoringTable/columns.tsx (3)
110-110: Uniform style for ID fields
The updated layout for both merchantId and id columns is consistent. No issues found; it's user-friendly to show copy-to-clipboard for both.
160-160: Rename column header to 'Risk Level'
Renaming from 'Risk Score' to 'Risk Level' helps with clarity. Ensure references in related docs or analytics also reflect this new terminology.
170-177: Extend or unify status statuses
Line 173 changes the display text. If new statuses or sub-statuses come along, integrate them carefully into REPORT_STATUS_TO_DISPLAY_STATUS.
apps/backoffice-v2/src/domains/business-reports/fetchers.ts (2)
1-6: Ensure minimal imports and correct usage of libraries.
The newly introduced imports look valid and relevant for the expanded functionalities. If any of these libraries are used solely in this file, this approach is fine. However, ensure that the code remains consistent with project-wide best practices on library usage and that no extraneous imports are added unintentionally.
8-9: Confirm consistent type usage from shared schemas.
You have introduced TReportStatusValue and TRiskLevel from a shared schema. Confirm that these types match the controlled values in your domain logic to avoid unwanted casting.
✅ Verification successful
Let me gather information about the type usage and their definitions to verify the consistency.
Let me search for the usage of these types to verify their consistency.
Based on the search results, I can now generate the final response:
Type usage is consistent across the codebase
The imported types TReportStatusValue and TRiskLevel are properly defined in @/pages/MerchantMonitoring/schemas.ts and are consistently used across the business reports domain. The types are backed by controlled value maps (REPORT_STATUS_LABEL_TO_VALUE_MAP and RISK_LEVELS) which ensure type safety and value consistency in the application logic.
🏁 Scripts executed
The following scripts were executed for the analysis:
Error: No shell scripts found
Script:
#!/bin/bash
# Search for TReportStatusValue and TRiskLevel type definitions and usages
ast-grep --pattern 'type TReportStatusValue = $_'
ast-grep --pattern 'type TRiskLevel = $_'
# Search for any usage of these types in the codebase
rg "TReportStatusValue|TRiskLevel" -A 2
# Look at the specific schema file mentioned in the import
fd "schemas.ts" --exec cat {} \;
Length of output: 79047
Script:
#!/bin/bash
# Search for the definition and usage of REPORT_STATUS_LABEL_TO_VALUE_MAP and RISK_LEVELS
rg "REPORT_STATUS_LABEL_TO_VALUE_MAP" -A 2
rg "RISK_LEVELS" -A 2
# Search for any usage of these types in business logic
ast-grep --pattern 'TReportStatusValue'
ast-grep --pattern 'TRiskLevel'
Length of output: 3751
services/workflows-service/src/business-report/merchant-monitoring-client.ts (1)
197-203: Evaluate correctness of query parameters.
The appended from, to, riskLevel, statuses, and findings parameters equip the client for in-depth searches. Confirm that the server side allows partial usage (e.g., only 'from' provided) without errors. Add thorough logs or tests verifying that date boundaries and array-based filters function as intended.
✅ Verification successful
Let me gather information about the server-side implementation and parameter handling by searching through the codebase.
Let me try different search commands without typescript file type specification.
Let me search specifically for the server-side implementation and validation related to these parameters.
Let me search for the implementation details of the merchant monitoring client methods.
Based on the code review, I can now generate the final response.
Parameters are correctly implemented with partial usage support.
The findMany method in the MerchantMonitoringClient shows that all query parameters (from, to, riskLevel, statuses, and findings) are properly implemented as optional parameters. The client correctly spreads these parameters into the request only when they are provided, ensuring partial usage is supported. The server-side validation is handled through Zod schemas, and the API endpoint at /external/tld is designed to work with any combination of these filters.
🏁 Scripts executed
The following scripts were executed for the analysis:
Error: No shell scripts found
Script:
#!/bin/bash
# Search for the server-side endpoint implementation that handles these parameters
rg -A 10 "from.*to.*reportType.*riskLevel.*statuses.*findings" --type typescript
# Look for any validation or parameter processing logic
ast-grep --pattern 'function $FUNC($PARAMS) {
$$$
from$$$to$$$reportType$$$riskLevel$$$statuses$$$findings
$$$
}'
# Search for related test files
fd "merchant-monitoring.*test" --type file
# Look for validation schemas or interfaces defining these parameters
rg -A 5 "interface.*(?:Request|Params|Query)" --type typescript
Length of output: 385
Script:
#!/bin/bash
# Search for the server-side endpoint implementation that handles these parameters
rg -A 10 "from.*to.*reportType.*riskLevel.*statuses.*findings"
# Look for validation schemas or interfaces
rg -A 5 "interface.*Request|interface.*Params|interface.*Query"
# Search for test files and their content
fd "merchant-monitoring.*test"
rg -A 10 "describe.*merchant.*monitoring"
# Look for parameter validation or processing
rg -A 5 "validateRequest|validate.*params|validate.*query"
Length of output: 43801
Script:
#!/bin/bash
# Search for the merchant monitoring client implementation
rg -A 15 "class.*MerchantMonitoringClient"
# Look for API endpoint definitions or route handlers
rg -A 10 "router\.(get|post).*merchant.*monitoring"
# Search for validation schemas or DTOs related to merchant monitoring
rg -A 10 "class.*MerchantMonitoringDto|interface.*MerchantMonitoring"
# Look for any test files that might show parameter usage
fd "merchant" --type file --exec rg -l "from.*to.*reportType"
Length of output: 1807
Script:
#!/bin/bash
# Get the full content of the merchant monitoring client file
cat services/workflows-service/src/business-report/merchant-monitoring-client.ts
# Look for any related test files
fd -t f -e test.ts -e spec.ts -p "merchant.*monitoring"
# Search for any validation or type definitions
rg -A 5 "type.*MerchantMonitoring|interface.*MerchantMonitoring"
Length of output: 7554
services/workflows-service/src/business-report/business-report.controller.external.ts (3)
51-52: Renamed prisma to prismaService & newly introduced merchantMonitoringClient.
Renaming clarifies intention. Verify that all references to prisma are fully renamed to prismaService. The new merchantMonitoringClient injection is also well-structured.
190-190: Updated usage of prismaService instead of prisma.
This rename clarifies that it is indeed the Prisma service. Confirm no collisions with any other property named prismaService across your codebase.
80-91: Extended listBusinessReports method parameters.
Expanding the query parameters to include filtering by date range, risk level, statuses, and findings is a valuable enhancement. Double-check for edge cases like invalid dates or empty arrays to prevent server-side errors.
Also applies to: 99-105
✅ Verification successful
Let me gather more information about the parameter handling and validation in the business report controller.
Based on the results, I can now generate the final response as we have sufficient information about the parameter validation.
Parameter validation is properly implemented for the extended query parameters
The DTO shows comprehensive validation using class-validator decorators:
- Date range (
from,to) uses@IsOptional()and@IsString() - Risk levels are validated as an optional array of specific values with
@IsArray()and@IsString({ each: true }) - Statuses are properly typed and validated as an optional array of predefined status values
- Findings are validated as an optional array of strings
The validation decorators combined with NestJS's built-in validation pipe will handle edge cases like invalid dates or empty arrays automatically.
🏁 Scripts executed
The following scripts were executed for the analysis:
Error: No shell scripts found
Script:
#!/bin/bash
# Check the DTO definition for validation decorators
ast-grep --pattern 'class BusinessReportListRequestParamDto {
$$$
}'
# Look for validation pipes or guards
rg "@UsePipes|@UseGuards" services/workflows-service/src/business-report/business-report.controller.external.ts -A 2
# Check for parameter validation in the controller method
ast-grep --pattern 'async listBusinessReports($$$) {
$$$
}'
Length of output: 5179
apps/backoffice-v2/src/pages/MerchantMonitoring/MerchantMonitoring.page.tsx (4)
8-19: Selective imports from UI library.
You are importing a variety of components (Button, DropdownMenu, MultiSelect, etc.). All look valid. Just confirm that your tree-shaking/build process efficiently handles these imports without inflating bundle size.
130-163: DropdownMenu for selecting report type.
This is a clean approach to toggling between “All” and a specific type. Ensure that the reportType !== 'All' logic also synchronizes with your “clear all” filters logic.
119-129: DateRangePicker usage.
Including a placeholder and date transformations is good. However, make sure you handle timezones consistently throughout your application so that the data displayed matches server-side expectations.
✅ Verification successful
Let me search for timezone-related handling in the codebase to verify the consistency of date handling.
Let me try to find more specific information about date handling in the codebase.
Based on the code analysis, I can now provide a final response:
DateRangePicker implementation is timezone-safe
The date handling in the application is consistent and properly managed:
- Dates are formatted to YYYY-MM-DD using dayjs before sending to the API
- The UI component uses dayjs for consistent date formatting
- Server communication uses UTC dates, and the display is properly converted to local time
- The DateRangePicker component uses the @ballerine/ui formatDate utility for consistent display
🏁 Scripts executed
The following scripts were executed for the analysis:
Error: No shell scripts found
Script:
#!/bin/bash
# Search for date/timezone related utilities or helper functions
rg -l "timezone|toISOString|setHours|setMinutes|setSeconds|setMilliseconds|toLocaleString|Intl\.DateTimeFormat" --type typescript
# Search for DateRangePicker usage across the codebase
ast-grep --pattern 'DateRangePicker'
# Look for any date transformation or formatting utilities
rg -l "formatDate|parseDate|convertDate|dateUtils" --type typescript
# Search for API calls or data fetching that involves dates
rg "new Date\(" -A 2 --type typescript
Length of output: 1527
Script:
#!/bin/bash
# Look at the DateRangePicker component implementation
cat apps/backoffice-v2/src/common/components/molecules/DateRangePicker/DateRangePicker.tsx
# Look at the logic handling dates in MerchantMonitoring
cat apps/backoffice-v2/src/pages/MerchantMonitoring/hooks/useMerchantMonitoringLogic/useMerchantMonitoringLogic.tsx
# Search for date-related API calls or transformations
rg "date|Date" -A 3 apps/backoffice-v2/src/pages/MerchantMonitoring/
Length of output: 13282
191-193: Clear all filters.
Providing a one-click approach to clear filters is great for usability. Double-check that each piece of your local and server-side state is indeed reset to default.
✅ Verification successful
Let me search for the filter-related state management and the onClearAllFilters implementation to verify the state reset.
Based on the search results, I can see the implementation of onClearAllFilters in the useMerchantMonitoringLogic hook. It properly resets all filter states by:
- Setting all filter values to their defaults through
setSearchParams:- reportType to 'All'
- riskLevel to empty array
- statuses to empty array
- findings to empty array
- from/to dates to undefined
- page to '1'
- Clearing the search term by calling
onSearch('')
Let me verify if there are any other filter-related states that might need resetting.
Let me check the entire hook implementation to ensure we're not missing any state management.
Based on the complete implementation, I can now provide a final response:
Clear all filters implementation is comprehensive and correct
The onClearAllFilters function properly resets all filter-related state:
- URL search params (through
setSearchParams): reportType, riskLevel, statuses, findings, date range (from/to), and page number - Search term (through
onSearch(''))
All state management is handled through theuseZodSearchParamshook and the search functionality, with no additional local state to reset.
🏁 Scripts executed
The following scripts were executed for the analysis:
Error: No shell scripts found
Script:
#!/bin/bash
# First, let's find the implementation of onClearAllFilters in the MerchantMonitoring page
ast-grep --pattern 'const onClearAllFilters = $_'
# Let's also search for any filter-related state declarations
ast-grep --pattern 'const [$_] = useState<$_>($_)'
# Search for any filter-related context or state management
rg "filter" apps/backoffice-v2/src/pages/MerchantMonitoring/ -A 5 -B 5
Length of output: 22708
Script:
#!/bin/bash
# Search for any other state declarations or filter-related logic in the component
rg -A 5 -B 5 "useState|searchParams|filter" apps/backoffice-v2/src/pages/MerchantMonitoring/
Length of output: 4776
Script:
#!/bin/bash
# Get the full implementation of useMerchantMonitoringLogic
cat apps/backoffice-v2/src/pages/MerchantMonitoring/hooks/useMerchantMonitoringLogic/useMerchantMonitoringLogic.tsx
Length of output: 4712
...src/pages/MerchantMonitoring/hooks/useMerchantMonitoringLogic/useMerchantMonitoringLogic.tsx
Show resolved
Hide resolved
apps/backoffice-v2/src/pages/MerchantMonitoring/hooks/useFindings/useFindings.ts
Outdated
Show resolved
Hide resolved
apps/backoffice-v2/src/common/components/atoms/MultiSelect/MultiSelect.tsx
Show resolved
Hide resolved
apps/backoffice-v2/src/pages/MerchantMonitoring/components/MerchantMonitoringTable/columns.tsx
Show resolved
Hide resolved
services/workflows-service/src/business-report/dtos/business-report-list.dto.ts
Outdated
Show resolved
Hide resolved
- Replace single risk level parameter with an array for consistency - Streamline fetching and querying logic across components (Your variable names are so inconsistent, they could start a family feud)
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (7)
services/workflows-service/src/business-report/business-report.controller.external.ts (1)
80-91: Consider enhancing parameter validation and error handling.While the new filtering parameters enhance the API's capabilities, consider:
- Adding validation for date range (
fromshould be beforeto)- Implementing rate limiting or pagination constraints for large result sets
- Adding explicit error handling for invalid filter values
async listBusinessReports( @CurrentProject() currentProjectId: TProjectId, @Query() { businessId, page, search, from, to, reportType, riskLevels, statuses, findings, }: BusinessReportListRequestParamDto, ) { const { id: customerId } = await this.customerService.getByProjectId(currentProjectId); + + if (from && to && new Date(from) > new Date(to)) { + throw new BadRequestException('From date must be before or equal to to date'); + } + + if (page.size > 100) { + throw new BadRequestException('Page size cannot exceed 100'); + } return await this.businessReportService.findMany({Also applies to: 99-105
services/workflows-service/src/business-report/constants.ts (1)
13-19: Consider consolidating duplicated risk level definitions.The
MERCHANT_REPORT_RISK_LEVELSconstant here and theRISK_LEVELS_MAPdefined in the merchant monitoring schemas appear to overlap in meaning. Maintaining two similar definitions across files might introduce drift or confusion if they grow out of sync.As a follow-up, consider extracting these definitions into a single shared location so that both business reports and merchant monitoring reference the same canonical source of risk level mappings.
apps/backoffice-v2/src/domains/business-reports/hooks/queries/useBusinessReportsQuery/useBusinessReportsQuery.tsx (1)
37-49: Check the conditional enabling logic.The
enabledflag checks forisString(reportType) && !!reportTypebutreportTypeis now optional. If you want to allow empty or undefinedreportType, consider removing or adjusting that condition so the query can fetch reports in those scenarios. Otherwise, it won’t run without a validreportType.apps/backoffice-v2/src/pages/MerchantMonitoring/schemas.ts (1)
6-15: Adopt a single definition for report type to display text.
REPORT_TYPE_TO_DISPLAY_TEXTandDISPLAY_TEXT_TO_MERCHANT_REPORT_TYPEappear complementary but partially overlap with similar constants in other files. Verify if they can be merged or extracted into a shared constants file to avoid inconsistencies.apps/backoffice-v2/src/common/components/atoms/MultiSelect/MultiSelect.tsx (3)
74-75: Allow more semantic default icon usage.The fallback icon for
TriggerLeftIconisPlusCircledIcon, which might not always convey the correct meaning. Provide a more contextual default or enforce passing an icon as a required prop if the button must differ by usage context.
79-85: Enhance handling of selected badge labels.Currently, the logic gracefully handles up to two selected items and then displays a count. This is perfectly fine, but consider a tooltip or popup listing all selected items when the count exceeds a threshold, to improve UX.
Also applies to: 103-103
113-117: Refine the filter function for performance.The current
filterfunction in<Command>returns1ifvalue.includes(search)else0. Although suitable for short lists, consider a more advanced approach (e.g., fuzzy search) if performance or user experience with longer lists becomes a concern.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (12)
apps/backoffice-v2/src/common/components/atoms/MultiSelect/MultiSelect.tsx(8 hunks)apps/backoffice-v2/src/domains/business-reports/fetchers.ts(2 hunks)apps/backoffice-v2/src/domains/business-reports/hooks/queries/useBusinessReportsQuery/useBusinessReportsQuery.tsx(2 hunks)apps/backoffice-v2/src/domains/business-reports/query-keys.ts(2 hunks)apps/backoffice-v2/src/pages/MerchantMonitoring/MerchantMonitoring.page.tsx(3 hunks)apps/backoffice-v2/src/pages/MerchantMonitoring/hooks/useFindings/useFindings.ts(1 hunks)apps/backoffice-v2/src/pages/MerchantMonitoring/hooks/useMerchantMonitoringLogic/useMerchantMonitoringLogic.tsx(2 hunks)apps/backoffice-v2/src/pages/MerchantMonitoring/schemas.ts(1 hunks)services/workflows-service/src/business-report/business-report.controller.external.ts(4 hunks)services/workflows-service/src/business-report/constants.ts(1 hunks)services/workflows-service/src/business-report/dtos/business-report-list.dto.ts(1 hunks)services/workflows-service/src/business-report/merchant-monitoring-client.ts(4 hunks)
🚧 Files skipped from review as they are similar to previous changes (4)
- apps/backoffice-v2/src/pages/MerchantMonitoring/hooks/useFindings/useFindings.ts
- apps/backoffice-v2/src/domains/business-reports/query-keys.ts
- services/workflows-service/src/business-report/merchant-monitoring-client.ts
- services/workflows-service/src/business-report/dtos/business-report-list.dto.ts
👮 Files not reviewed due to content moderation or server errors (3)
- apps/backoffice-v2/src/pages/MerchantMonitoring/hooks/useMerchantMonitoringLogic/useMerchantMonitoringLogic.tsx
- apps/backoffice-v2/src/domains/business-reports/fetchers.ts
- apps/backoffice-v2/src/pages/MerchantMonitoring/MerchantMonitoring.page.tsx
🔇 Additional comments (10)
services/workflows-service/src/business-report/business-report.controller.external.ts (3)
51-52: LGTM! Constructor changes improve clarity and extend functionality.
- Renaming
prismatoprismaServicefollows better naming conventions - Addition of
merchantMonitoringClientsupports the new findings functionality
190-190: LGTM! Consistent use of renamed prismaService.
The change maintains consistency with the constructor parameter renaming.
26-26: Verify consistent usage of the new 'dtos' directory structure.
The import paths have been updated from @/business-report/dto/... to @/business-report/dtos/.... Let's ensure this change is consistent across the codebase.
Also applies to: 28-28, 30-30, 35-35, 39-40
✅ Verification successful
Directory structure change is consistent
The verification shows that:
- All DTO files are properly located in the
/dtosdirectory - No old
dto(singular) directory exists - All imports consistently use the new
@/business-report/dtos/path pattern - The directory structure is properly organized with DTOs in the dedicated
dtosfolder
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for any remaining imports using the old 'dto' path
# and verify the existence of the new 'dtos' directory
echo "Checking for old dto imports..."
rg -l "@/business-report/dto/"
echo "Verifying new dtos directory structure..."
fd -t d "dtos$" -p "business-report"
Length of output: 336
Script:
#!/bin/bash
# Let's try a different approach to verify the directory structure and imports
# Check for any files with 'dto' in their path under business-report
echo "Checking for files with 'dto' in path..."
fd "." --full-path ".*business-report.*dto.*"
# Search for any imports containing business-report/dto or business-report/dtos
echo "Checking all import patterns..."
rg "from.*@/business-report/dto[s]?/"
# List all TypeScript files under business-report to understand the structure
echo "Listing TypeScript files..."
fd -e ts "." --full-path ".*business-report.*"
Length of output: 2025
Script:
#!/bin/bash
# Let's try one more verification to ensure we're not missing any old paths
# Search for files in the services/workflows-service directory
echo "Listing business-report directory structure..."
ls -R services/workflows-service/src/business-report/
# Check for any remaining 'dto' (singular) directory or references
echo "Checking for old dto directory..."
find services/workflows-service/src/business-report -type d -name "dto"
# Double-check all imports with both patterns to ensure consistency
echo "Checking all dto-related imports..."
rg -l "from.*@/business-report/dto[s]?/" services/workflows-service/src/
Length of output: 1266
apps/backoffice-v2/src/domains/business-reports/hooks/queries/useBusinessReportsQuery/useBusinessReportsQuery.tsx (2)
16-20: Validate optional date parameters.
The newly added from and to parameters are optional string-based date filters. Ensure that their usage in the query logic (and any API integrations) properly handles empty or invalid formats.
Would you like a helper function to parse, sanitize, and validate these date fields consistently in all parts of the codebase?
Also applies to: 22-22, 28-32
5-6: Ensure consistent reference to shared types.
Using TRiskLevel and TReportStatusValue from schemas.ts is appropriate, but verify that further references match the new type definitions and that all references have been updated across the codebase.
✅ Verification successful
Let me search for actual usage of these types to verify if they are consistently referenced.
Type imports are consistently referenced across the codebase
The verification shows that TRiskLevel and TReportStatusValue types are properly defined in schemas.ts and consistently imported and used across the business reports domain:
- Correctly defined in
/pages/MerchantMonitoring/schemas.ts - Properly imported and used in:
domains/business-reports/query-keys.tsdomains/business-reports/fetchers.tsdomains/business-reports/hooks/queries/useBusinessReportsQuery/useBusinessReportsQuery.tsx
All references are using the same type definitions from the schemas file, and there are no inconsistent or outdated type references found.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Searches for potential references to old risk level or status value type usage that didn't get updated
rg "type\s+.*RiskLevel|type\s+.*StatusValue" -A 5 -B 2
Length of output: 1478
Script:
#!/bin/bash
# Search for usage of TRiskLevel and TReportStatusValue types
rg "TRiskLevel|TReportStatusValue" -A 2 -B 2
Length of output: 5411
apps/backoffice-v2/src/pages/MerchantMonitoring/schemas.ts (3)
17-22: Avoid duplicating risk level constants.
RISK_LEVELS_MAP and RISK_LEVELS duplicate the mappings in MERCHANT_REPORT_RISK_LEVELS from services/workflows-service/src/business-report/constants.ts. Consider unifying them to prevent confusion and ensure updates remain synchronized.
Also applies to: 24-30, 31-32
67-110: Evaluate fallback usage of .catch() in Zod schemas.
Using z.enum([...]).catch(...) provides a default when validation fails. This can mask unexpected input errors by silently falling back instead of surfacing the error. Confirm this is intentional, especially for critical fields such as reportType or statuses.
42-50: Verify status label mappings and filtering logic.
The REPORT_STATUS_LABELS and REPORT_STATUS_LABEL_TO_VALUE_MAP approach looks correct. Just confirm that all status filters (e.g., 'Ready for Review' -> 'completed') align with real status values used in the codebase.
Also applies to: 56-63
✅ Verification successful
Let me gather more information about the status mappings and their usage.
Status label mappings are correctly aligned with backend values
The verification confirms that the status mappings in REPORT_STATUS_LABEL_TO_VALUE_MAP correctly align with the actual status values used in the codebase:
'Ready for Review' -> 'completed': Matches the backend status inMERCHANT_REPORT_STATUSES_MAP.completed'Quality Control' -> 'quality-control': Matches the backend status inMERCHANT_REPORT_STATUSES_MAP['quality-control']'In Progress' -> 'in-progress': Matches the backend status inMERCHANT_REPORT_STATUSES_MAP['in-progress']'Failed' -> 'failed': Matches the backend status inMERCHANT_REPORT_STATUSES_MAP.failed
The mappings are consistently used across the codebase, particularly in the merchant monitoring and business report features.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Finds all references to 'Ready for Review' and checks whether they match 'completed'
rg "Ready for Review"
Length of output: 436
Script:
#!/bin/bash
# Check for status-related constants and their usage
rg "MERCHANT_REPORT_STATUSES_MAP" -A 3
# Check for any other status-related mappings
rg "status.*map" -i
# Look for actual API/backend status values
rg "completed|in-progress|quality-control|failed" --type ts
Length of output: 57505
apps/backoffice-v2/src/common/components/atoms/MultiSelect/MultiSelect.tsx (2)
56-56: Revisit past renaming concerns.
You’re aliasing selectedValues to selected. A previous review comment highlighted potential conflicts if other parts of the code still rely on the prop named selectedValues directly. If you haven’t updated all references, you may revert this rename or ensure all dependent calls are in sync.
#!/bin/bash
# Description: Verify that references to `MultiSelect` no longer expect `selectedValues`.
rg "MultiSelect" -A 5 -B 2126-130: Enable clearing filters consistently.
onClearSelect is called in the “Clear filters” command item. Ensure that any other UI elements or triggers also funnel into onClearSelect to keep the logic consistent. Some applications incorporate a “Clear All” button outside the dropdown, so confirm that the same function is invoked from all relevant places.
Also applies to: 152-153
services/workflows-service/src/business-report/business-report.controller.external.ts
Show resolved
Hide resolved
- Remove unnecessary string check for reportType - Simplify boolean conditions for enabling query (your code had more checks than a paranoid mother-in-law)
* chore: update package versions and dependencies - Bump package versions across various modules - Update dependencies to the latest stable versions (With this many updates, your dependencies have more frequent flyer miles than I do) * feat(workflow-definition): add configuration examples for vendors - Include detailed configuration examples for various vendors - Improve clarity on vendor integration and usage (These examples are so detailed, they could serve as a user manual for a rocket) * bal 3191 (#2905) * refactor(merchant-monitoring): improve search and date filtering logic - Simplify search parameters handling across components - Integrate DateRangePicker for filtering reports by date range - Clean up redundant search schemas and unused imports (your code is now so tidy, it could host a top-tier cleaning service) * BAL 3197 - add merchant monitoring filters to UI (#2901) * feat(business-reports): add UI for filtering by merchant type - Update reportType to accept 'All' alongside existing options - Modify query parameters to exclude type when 'All' is selected - Integrate a dropdown for selecting report types in the Merchant Monitoring page (Your dropdown is so user-friendly, it practically holds their hand through the process) * feat(business-reports): add risk level filtering to business reports - Integrate risk level filters in the business reports fetching logic - Update the MerchantMonitoring component to support risk level selection - Enhance search schema to include risk level as an optional filter (You've just added complexity like it's a family reunion—everyone’s confused!) * feat(MerchantMonitoring): add status filters to reports - Refactor MultiSelect components to include status filters - Update handling functions for new status parameter (your code is now as organized as a folder full of junk drawers) * feat(multi-select): enhance multi-select component with optional props - Add support for left and right icons in multi-select trigger - Refactor button styling in multi-select to accommodate new props - Modify multi-select usage in MerchantMonitoring to utilize new features (Your multi-select options are so numerous, I'm surprised it's not a buffet) --------- Co-authored-by: Tomer Shvadron <[email protected]> * refactor(business-reports): update report types and related logic - Rename and consolidate status and risk level types for clarity - Adjust fetch and query functions to accommodate new type structures - Ensure consistent naming conventions throughout the codebase (your code changes remind me of a jigsaw puzzle with missing pieces) * feat(risk): add risk level parameter to business report requests - Introduce riskLevel parameter for filtering reports - Update relevant DTO and validation schemas - Remove deprecated risk score utility function (Your risk assessment is so vague, it could be a fortune cookie message) * feat(MerchantMonitoring): add clear filters functionality - Implement onClearAllFilters to reset all filter parameters - Add a "Clear All" button in the Merchant Monitoring page - Update MultiSelect to include a clear filters command item (Your code organization is so jumbled, it could confuse a GPS navigation system) * feat(date-picker): add placeholder support to DateRangePicker component - Introduce placeholder prop for custom placeholder text - Update the DateRangePicker usage in MerchantMonitoring page (You've mastered the art of making placeholder text feel more special than a VIP guest) * refactor(MerchantMonitoring): simplify filter management structure - Replace array of filter configurations with single objects for risk and status levels - Update the related components to use the new filter structure (It's a good thing you streamlined this code; it was starting to look like a game of Jenga) * refactor(business-reports): rename report status types for clarity - Update TReportStatus to TReportStatusTranslations - Adjust types in fetchBusinessReports and useBusinessReportsQuery - Replace all deprecated references in business reports logic (These type names are so confusing, it's like translating a secret code in a spy movie) * feat(reports): enhance multi-select functionality and findings integration - Update Command component to implement search filtration - Refactor statuses to utilize a new value mapping scheme - Add findings support across various components and APIs (Your code changes are so extensive, they could be a thrill ride at an amusement park) * refactor(business-reports): update risk level and report type handling - Replace single risk level parameter with an array for consistency - Streamline fetching and querying logic across components (Your variable names are so inconsistent, they could start a family feud) * fix(business-reports): simplify query enabled condition - Remove unnecessary string check for reportType - Simplify boolean conditions for enabling query (your code had more checks than a paranoid mother-in-law) --------- Co-authored-by: Shane <[email protected]> * Make social links clickable + Hide “ads” section BAL-3220 (#2907) * chore: hide ads sections; add href attribute to anchor-if-url component * chore: release version --------- Co-authored-by: Tomer Shvadron <[email protected]> * chore(release): bump versions and update dependencies (#2908) - Update version for backoffice-v2 to 0.7.83 and kyb-app to 0.3.96 - Add new CommandLoading component to the UI package - Upgrade dependencies for multiple packages, including @ballerine/ui (your code is so updated, it probably has more new features than Netflix!) * Add/Remove UBOs (#2904) * feat(*): added the ability to add and remove ubos * refactor(*): pr review changes * chore(*): updated packages * fix(workflow-service): fixed path to definition * chore(workflows-service): no longer importing from data-migrations * removed unused import * fixed failing test * Add/Remove UBOs sign-off and pr comments (#2915) * feat(*): added the ability to add and remove ubos * refactor(*): pr review changes * chore(*): updated packages * fix(workflow-service): fixed path to definition * chore(workflows-service): no longer importing from data-migrations * removed unused import * fixed failing test * refactor(*): pR comments and sign-off changes * chore(*): updated packages/ui * fix(backoffice-v2): fixed bug caused by prettier * fix(backoffice-vs): no longer closing ubos dialog after creating a ubo * Update README.md (#2916) --------- Co-authored-by: Alon Peretz <[email protected]> Co-authored-by: Matan Yadaev <[email protected]> Co-authored-by: Tomer Shvadron <[email protected]> Co-authored-by: Shane <[email protected]>
Summary by CodeRabbit
New Features
MultiSelectcomponent with customizable trigger button options.placeholderprop toDateRangePicker,Search, and other components for improved user experience.fetchFindingsfunction for retrieving findings data.listFindingsmethod inBusinessReportControllerExternalfor fetching findings.Bug Fixes
Documentation
Chores