BAL 3197 - add merchant monitoring filters to UI #2901
Conversation
- 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)
- 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!)
- 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)
|
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the WalkthroughThis pull request introduces comprehensive enhancements to the Merchant Monitoring and Business Reports functionality across multiple files. The changes primarily focus on expanding filtering capabilities, adding support for risk levels and status options, and improving the user interface for selecting and managing business reports. The modifications span several components and hooks, introducing new state management, filtering mechanisms, and query parameter handling to provide more granular control over report data. Changes
Possibly related PRs
Suggested Labels
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: 1
🧹 Nitpick comments (10)
apps/backoffice-v2/src/pages/MerchantMonitoring/MerchantMonitoring.page.tsx (3)
24-24: MultiSelect import
MultiSelect is essential for multi-value filtering. Confirm that the component is properly documented and tested.
110-110: UI spacing change
Changing to flex gap-2 is a neat improvement in modern CSS, ensuring a uniform gap.
143-152: Status MultiSelect
Similarly, the new Status filter multi-select is consistent. Ensure that combined usage of riskLevel & status queries is tested thoroughly.apps/backoffice-v2/src/domains/business-reports/hooks/queries/useBusinessReportsQuery/useBusinessReportsQuery.tsx (1)
21-21: Expanded reportType
Allowing 'All' in the union type is consistent with an all-encompassing filter. Ensure usage is properly handled downstream.apps/backoffice-v2/src/pages/MerchantMonitoring/get-merchant-monitoring-search-schema.ts (1)
22-22: New sort field: 'reportType'
Allowing sorting by report type might be less common, but it’s consistent with the feature set. Make sure the UI surfaces this appropriately.apps/backoffice-v2/src/pages/TransactionMonitoringAlerts/components/AlertsFilters/AlertsFilters.tsx (1)
81-81: LGTM! Consider adding a type guard for unique titles.The change to use
titledirectly as the key is valid since titles are unique within the filters array. However, consider adding a type guard to ensure title uniqueness at compile time.type EnsureUniqueTitles<T extends readonly { title: string }[]> = T extends [] ? [] : T extends [infer Head, ...infer Tail] ? Head extends { title: string } ? Tail extends { title: Head['title'] }[] ? never : [Head, ...EnsureUniqueTitles<Tail & { title: string }[]>] : never : never; // Usage: const filters: EnsureUniqueTitles<typeof filters> = [...];apps/backoffice-v2/src/pages/MerchantMonitoring/hooks/useMerchantMonitoringLogic/useMerchantMonitoringLogic.tsx (3)
22-23: Consider making risk levels and status options configurable.The hardcoded values for
RISK_LEVELSandSTATUS_OPTIONSmight need to be configurable based on backend configuration or customer requirements.Consider fetching these values from an API endpoint or configuration service to make them more maintainable and flexible.
Also applies to: 35-35
83-91: Consider notifying users about page reset.The filter change handler resets the page to '1', which might be unexpected for users if they're on a different page.
Consider adding a toast notification when the page is reset due to filter changes:
const handleFilterChange = useCallback( (filterKey: string) => (selected: unknown) => { + const wasOnDifferentPage = page !== '1'; setSearchParams({ [filterKey]: Array.isArray(selected) ? selected : [selected], page: '1', }); + if (wasOnDifferentPage) { + toast.info('Filters changed. Returning to first page.'); + } }, [setSearchParams, page], );
66-69: Simplify report type mapping.The nested access to
DISPLAY_TEXT_TO_MERCHANT_REPORT_TYPEcould be simplified.- reportType: - DISPLAY_TEXT_TO_MERCHANT_REPORT_TYPE[ - reportType as keyof typeof DISPLAY_TEXT_TO_MERCHANT_REPORT_TYPE - ], + reportType: DISPLAY_TEXT_TO_MERCHANT_REPORT_TYPE[reportType] ?? 'All',apps/backoffice-v2/src/domains/business-reports/fetchers.ts (1)
17-20: Consider moving constants to domain layerThe import of UI-specific constants (
RISK_LEVELS,STATUS_OPTIONS) from a UI logic hook into the data fetching layer violates separation of concerns. These constants represent domain concepts and should be defined in the business reports domain, possibly alongside other constants inconstants.ts.Consider moving these constants to
domains/business-reports/constants.tsto maintain proper architectural boundaries.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (9)
apps/backoffice-v2/src/common/components/atoms/MultiSelect/MultiSelect.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/MerchantMonitoring/MerchantMonitoring.page.tsx(3 hunks)apps/backoffice-v2/src/pages/MerchantMonitoring/get-merchant-monitoring-search-schema.ts(2 hunks)apps/backoffice-v2/src/pages/MerchantMonitoring/hooks/useMerchantMonitoringLogic/useMerchantMonitoringLogic.tsx(3 hunks)apps/backoffice-v2/src/pages/TransactionMonitoringAlerts/components/AlertsFilters/AlertsFilters.tsx(1 hunks)services/workflows-service/prisma/data-migrations(1 hunks)
✅ Files skipped from review due to trivial changes (1)
- services/workflows-service/prisma/data-migrations
🔇 Additional comments (20)
apps/backoffice-v2/src/pages/MerchantMonitoring/MerchantMonitoring.page.tsx (5)
8-8: Good practice: Icons import for UI enhancement
Importing SlidersHorizontal from lucide-react extends the available UI elements and is aligned with the new filtering controls. Looks good.
42-50: State management additions
The new properties (riskLevel, status, reportType) and functions (onReportTypeChange, handleFilterChange, handleFilterClear) are consistent with implementing multi-faceted filters. Great job ensuring the logic is centralized in useMerchantMonitoringLogic.
133-142: Risk level MultiSelect
Filtering by risk level is a valuable addition. Verify that the correct risk levels are displayed.
✅ Verification successful
Let me check the RISK_LEVEL_FILTERS definition to ensure it's correctly using the RISK_LEVELS.
Risk level implementation verified
The risk levels are correctly implemented. The RISK_LEVELS constant defines four levels: 'Critical', 'High', 'Medium', 'Low', which are properly mapped to the MultiSelect component's options with correct labels and values. The implementation maintains type safety through TypeScript and consistently uses these values across the codebase.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
#!/bin/bash
# Check if risk levels (RISK_LEVEL_FILTERS) usage matches RISK_LEVELS definition
rg -A 2 'RISK_LEVELS' || true
Length of output: 4075
Script:
#!/bin/bash
# Check RISK_LEVEL_FILTERS definition and usage
rg -A 5 'const RISK_LEVEL_FILTERS' || true
Length of output: 862
112-131: DropdownMenu for report types
- The SlidersHorizontal icon is visually coherent with the notion of “filter” or “options.”
- Good approach using DropdownMenuCheckboxItem for selection.
- Confirm that “All” or default selection is handled if the user does not pick a specific type.
✅ Verification successful
Let me gather more information about the default state and initialization of the reportType.
Let me check one more thing about the initialization and URL params handling.
Based on the gathered information, I can now provide the final response:
"All" type is properly handled in the implementation ✅
The implementation properly handles the "All" type through multiple layers:
- It's defined as a valid option in
REPORT_TYPE_TO_DISPLAY_TEXTwithAll: 'All' - The type system accounts for it with
MerchantReportType | 'All'in query parameters - The backend API handles it by excluding the type filter when
reportType === 'All' - The dropdown UI correctly displays and manages the "All" option alongside other report types
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Verify that the new Default or "All" usage is handled.
rg -A 2 'reportType.*All' || true
Length of output: 1312
Script:
#!/bin/bash
# Check for reportType initialization and default state
ast-grep --pattern 'const [reportType, setReportType] = useState<$_>($_)'
# Check for REPORT_TYPE_TO_DISPLAY_TEXT definition
rg -A 5 'REPORT_TYPE_TO_DISPLAY_TEXT.*=' || true
# Check for MerchantReportType definition
rg 'type MerchantReportType' -A 5 || true
Length of output: 7835
Script:
#!/bin/bash
# Check for URL params handling and initialization
rg -A 10 'const.*searchParams' apps/backoffice-v2/src/pages/MerchantMonitoring/ || true
# Check for default report type handling
rg -B 3 -A 3 'setSearchParams.*reportType' apps/backoffice-v2/src/pages/MerchantMonitoring/ || true
Length of output: 1188
11-18: Verification of UI imports
These UI components (DropdownMenu, Button, etc.) are standard library elements. Ensure that the new filtering UI works properly in supported browsers.
✅ Verification successful
Based on the search results, I can see that the DropdownMenu components are built on top of Radix UI's primitives (@radix-ui/react-dropdown-menu) which is a well-tested, accessible component library. The components are properly structured with appropriate ARIA attributes and keyboard navigation support.
Let me verify the Button component usage as well to ensure it's properly implemented:
Let me try a different pattern to check the Button component implementation:
Based on the comprehensive analysis of both the DropdownMenu and Button components, I can now provide a final response:
UI components verified as production-ready
The DropdownMenu components are built on Radix UI primitives with proper accessibility support, and the Button component is properly implemented with React.forwardRef and includes standard variant/size props and accessibility features. Both are part of the @ballerine/ui package which is used across the application.
- The DropdownMenu uses @radix-ui/react-dropdown-menu which provides built-in browser compatibility and ARIA support
- The Button component is properly forwarded and supports variants, sizes, and the asChild pattern for composition
- Both components are used consistently throughout the codebase with proper props and event handlers
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for references to newly added DropdownMenu, Button, etc., usage.
rg -A 5 "DropdownMenu" || true
rg -A 5 "Button" || true
Length of output: 108844
Script:
#!/bin/bash
# Check Button component implementation and its usage
ast-grep --pattern 'Button = React.forwardRef<$_,$_>($$$)'
Length of output: 60
Script:
#!/bin/bash
# Check Button component implementation from @ballerine/ui
rg -A 10 "export.*Button" packages/ui/src/
Length of output: 8542
apps/backoffice-v2/src/domains/business-reports/hooks/queries/useBusinessReportsQuery/useBusinessReportsQuery.tsx (4)
6-9: Import risk/status constants
Bringing in RISK_LEVELS and STATUS_OPTIONS from the logic hook keeps the code DRY. Good modular approach.
27-28: Array types for riskLevel & status
Explicit array typing for riskLevel/status improves clarity.
33-42: New query key arguments
Incorporating riskLevel and status in the query key ensures React Query identifies unique caches for different filter combos. Perfect approach for robust caching.
18-19: Extended function params
riskLevel and status are arrays, allowing multi-value filtering. Confirm that the server supports multiple filter values.
apps/backoffice-v2/src/domains/business-reports/query-keys.ts (3)
9-12: Imports for risk/status
Reusing RISK_LEVELS and STATUS_OPTIONS in query keys keeps it consistent with the rest of the application.
28-29: New parameters: riskLevel & status
These added parameters allow advanced filtering. Confirm that they are used properly in the fetcher.
22-22: reportType updated to include 'All'
Expanding type coverage ensures a default or “all statuses” scenario. Properly align fetch logic to handle the 'All' case (i.e., no filtering).
✅ Verification successful
'All' type is properly handled in fetch logic
The verification shows that the 'All' case is correctly implemented in the fetchers.ts file. When reportType is 'All', the type parameter is omitted from the query parameters (...(reportType !== 'All' && { type: reportType })), effectively removing any type filtering, which is the expected behavior for showing all reports.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for usage of the 'All' type in fetchBusinessReports to confirm correct logic handling
rg -A 5 "reportType: 'All'"
Length of output: 35
Script:
#!/bin/bash
# Search for any usage of reportType in the codebase
rg -A 5 "reportType.*MerchantReportType"
# Search for any usage of 'All' in business reports related files
fd "business-reports" --exec rg -A 5 "'All'"
# Search for fetch logic handling in business reports
ast-grep --pattern 'function fetchBusinessReports($$$) { $$$ }'
Length of output: 15163
apps/backoffice-v2/src/pages/MerchantMonitoring/get-merchant-monitoring-search-schema.ts (3)
5-9: Logic imports
Importing logic constants ensures consistent filtering references. Great approach to keep a single source of truth.
42-61: riskLevel & status arrays
The schema extension supports arrays of valid filter options. The .catch([]) usage ensures no error for missing inputs.
33-40: New field in schema: reportType
Ensuring defaulting to 'All' is a good approach. Check if the server properly interprets 'All.'
✅ Verification successful
Let me check the fetcher implementation to understand how 'All' is handled.
Based on the evidence from the codebase, I can now provide a final response:
'All' report type is properly handled in the implementation
The server-side handling is correctly implemented as shown in the fetchers.ts where reportType !== 'All' is specifically checked, and the type parameter is only included in the request when a specific type is selected. The UI and data flow also properly support this through the REPORT_TYPE_TO_DISPLAY_TEXT and DISPLAY_TEXT_TO_MERCHANT_REPORT_TYPE mappings.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Confirm that the server or fetchers interpret 'All' as selecting all types
rg -A 5 "reportType.*All" || true
Length of output: 2403
Script:
#!/bin/bash
# Check the implementation of the fetcher and any related constants
ast-grep --pattern 'const REPORT_TYPE_TO_DISPLAY_TEXT = {$$$}'
Length of output: 64
Script:
#!/bin/bash
# Let's check the implementation details around report types and their handling
rg -A 10 "REPORT_TYPE_TO_DISPLAY_TEXT" || true
Length of output: 10434
apps/backoffice-v2/src/common/components/atoms/MultiSelect/MultiSelect.tsx (2)
42-42: LGTM! Parameter rename improves readability.
The rename from selectedValues to selected makes the code more concise while maintaining clarity.
125-125: LGTM! Simplified clear filters logic.
The simplified onSelect handler for clear filters improves code maintainability by removing unnecessary state management.
apps/backoffice-v2/src/pages/MerchantMonitoring/hooks/useMerchantMonitoringLogic/useMerchantMonitoringLogic.tsx (1)
28-31: Verify case sensitivity requirements for filter values.
Converting risk levels and status values to lowercase might cause issues if the backend expects exact case matching.
Also applies to: 41-44
✅ Verification successful
Let me analyze the search results to verify the case sensitivity requirements for risk levels.
Based on the search results, I can now provide a definitive response about the case sensitivity requirements for risk level values.
Converting risk levels to lowercase is safe and consistent with the backend expectations.
The evidence shows that:
- Risk levels are defined as constants in uppercase first letter format:
['Critical', 'High', 'Medium', 'Low'] - The backend database queries and metrics repository consistently use lowercase risk levels in comparisons:
riskLevel === 'low',riskLevel === 'medium', etc. - The conversion to lowercase is already a standardized pattern in the codebase, as seen in multiple places including the metrics repository and risk level mappings.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check backend API expectations for risk level and status values
rg -A 5 "riskLevel.*=|status.*=" --type ts
Length of output: 66519
Script:
#!/bin/bash
# Search for risk level constants and their usage
rg -A 3 "RISK_LEVELS|riskLevel.*=.*" --type ts apps/backoffice-v2/
Length of output: 15041
apps/backoffice-v2/src/domains/business-reports/fetchers.ts (2)
92-99: Consider adding validation for array parameters
The new array parameters riskLevel and status might benefit from additional validation:
- Empty arrays might need special handling
- Consider adding default values or making parameters optional
Let's verify the impact on existing callers:
108-112: Verify array parameter serialization
The current implementation might need special handling for array parameters in the query string. The qs.stringify options should be verified to ensure arrays are properly encoded.
Let's check the query string format:
Consider adding a test case to verify the query string format for array parameters.
✅ Verification successful
Based on the search results, I can now provide a final response:
Array parameters are handled consistently with other fetchers
The implementation is correct and consistent with other fetchers in the codebase. All fetchers use qs.stringify with { encode: false } option, which is the standard pattern across the application. The array parameters (riskLevel and status) will be properly serialized as they are passed directly to qs.stringify without any special handling, which is the correct approach for this codebase.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for tests or usage examples to verify array parameter handling
rg -A 5 "fetchBusinessReports.*riskLevel.*status"
Length of output: 51
Script:
#!/bin/bash
# Let's first check how fetchBusinessReports is implemented
ast-grep --pattern 'const fetchBusinessReports = $_'
# Also check for any query string handling or API client setup
rg -l "qs\.stringify|queryString|URLSearchParams"
# Let's also check for any test files related to business reports
fd "business.*\.test\.(ts|js|tsx|jsx)$"
Length of output: 20692
Script:
#!/bin/bash
# Let's check the qs.stringify usage in other fetchers to understand the pattern
rg -A 5 "qs\.stringify" apps/backoffice-v2/src/domains/
# Also check if there are any array parameter handling tests
rg "riskLevel.*status.*test" apps/backoffice-v2/src/domains/business-reports/
Length of output: 2879
...src/pages/MerchantMonitoring/hooks/useMerchantMonitoringLogic/useMerchantMonitoringLogic.tsx
Outdated
Show resolved
Hide resolved
tomer-shvadron
force-pushed
the
BAL-3197
branch
from
635c24a to
1fae9bb
Compare
- 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)
* 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]>
* 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
Bug Fixes
Documentation
Chores