-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: support split expense grouping for Netsuite #1079
feat: support split expense grouping for Netsuite #1079
Conversation
WalkthroughThe changes in this pull request introduce a new property, Changes
Possibly related PRs
Suggested labels
Suggested reviewers
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 (
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 1
🧹 Outside diff range and nitpick comments (2)
src/app/core/models/netsuite/netsuite-configuration/netsuite-export-setting.model.ts (2)
289-290
: Improve form control organizationThe new form controls break the logical grouping. Consider:
- Moving
searchOption
with other search-related controls (if any exist)- Moving
splitExpenseGrouping
next to other credit card expense-related controlsstatic mapAPIResponseToFormGroup(exportSettings: NetSuiteExportSettingGet | null): FormGroup { return new FormGroup({ // ... other controls ... creditCardExportType: new FormControl(exportSettings?.configuration?.corporate_credit_card_expenses_object), creditCardExportGroup: new FormControl(this.getExportGroup(exportSettings?.expense_group_settings?.corporate_credit_card_expense_group_fields)), creditCardExportDate: new FormControl(exportSettings?.expense_group_settings?.ccc_export_date_type), + splitExpenseGrouping: new FormControl(exportSettings?.expense_group_settings?.split_expense_grouping), bankAccount: new FormControl(exportSettings?.general_mappings?.reimbursable_account?.id ? exportSettings.general_mappings.reimbursable_account : null), // ... other controls ... nameInJournalEntry: new FormControl(exportSettings?.configuration?.name_in_journal_entry ? exportSettings?.configuration.name_in_journal_entry : this.getNameInJournalOptions()[0].value), + searchOption: new FormControl(''), - searchOption: new FormControl(''), - splitExpenseGrouping: new FormControl(exportSettings?.expense_group_settings?.split_expense_grouping) }); }
310-311
: Document the default split expense grouping choiceThe code defaults to
SplitExpenseGrouping.MULTIPLE_LINE_ITEM
when no value is provided. Please add a comment explaining why this default was chosen to help future maintainers understand the business logic.expense_group_settings: { // ... other settings ... ccc_export_date_type: exportSettingsForm.get('creditCardExportDate')?.value, + // Default to MULTIPLE_LINE_ITEM for split expenses to maintain backward compatibility split_expense_grouping: exportSettingsForm.get('splitExpenseGrouping')?.value ? exportSettingsForm.get('splitExpenseGrouping')?.value : SplitExpenseGrouping.MULTIPLE_LINE_ITEM },
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (4)
src/app/core/models/db/expense-group-setting.model.ts
(1 hunks)src/app/core/models/netsuite/netsuite-configuration/netsuite-export-setting.model.ts
(4 hunks)src/app/integrations/netsuite/netsuite-shared/netsuite-export-settings/netsuite-export-settings.component.html
(1 hunks)src/app/integrations/netsuite/netsuite-shared/netsuite-export-settings/netsuite-export-settings.component.ts
(1 hunks)
🔇 Additional comments (8)
src/app/core/models/db/expense-group-setting.model.ts (1)
10-10
:
Breaking Change: New required property added
Adding a required property split_expense_grouping
to ExpenseGroupSettingPost
is a breaking change that will affect all existing implementations and could cause runtime issues if not properly migrated.
Let's verify the impact:
src/app/core/models/netsuite/netsuite-configuration/netsuite-export-setting.model.ts (2)
6-6
: LGTM: Import statement follows existing patterns
The addition of SplitExpenseGrouping
to the enum imports is well-organized and consistent with the existing import structure.
240-240
: Verify validation requirements for split expense grouping
The splitExpenseGrouping
field has been added as a required field for credit card expenses. Please verify if this validation should be conditional based on creditCardExportType
, similar to other conditional validations in the getMandatoryField
method.
✅ Verification successful
Based on the search results, I can generate the final response since I have enough information to verify the validation requirements for split expense grouping:
Split expense grouping validation is correctly conditional
The validation requirement for splitExpenseGrouping
is correctly implemented as it is only required when creditCardExportType
is set to CREDIT_CARD_CHARGE
. This is evident from:
- The HTML template shows the field is conditionally displayed based on both feature flag and export type:
*ngIf="brandingFeatureConfig.featureFlags.exportSettings.splitExpenseGrouping && exportSettingForm.get('creditCardExportType')?.value === NetSuiteCorporateCreditCardExpensesObject.CREDIT_CARD_CHARGE"
- The model provides a default value when not specified:
split_expense_grouping: exportSettingsForm.get('splitExpenseGrouping')?.value ? exportSettingsForm.get('splitExpenseGrouping')?.value : SplitExpenseGrouping.MULTIPLE_LINE_ITEM
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for any conditional logic related to split expense grouping in the codebase
rg -g '*.ts' -g '*.html' -A 5 -B 5 'splitExpenseGrouping|split_expense_grouping'
Length of output: 62413
src/app/integrations/netsuite/netsuite-shared/netsuite-export-settings/netsuite-export-settings.component.ts (3)
71-71
: Verify integration points for the split expense grouping feature.
The new split expense grouping options need to be properly integrated with:
- Form control initialization in
mapAPIResponseToFormGroup()
- Custom watchers for handling value changes
- Export settings validation rules
Let's verify these integration points:
✅ Verification successful
Based on the search results, I can see that the split expense grouping feature is properly integrated across the codebase:
- Form control initialization is present in the NetSuite export settings model:
splitExpenseGrouping: new FormControl(exportSettings?.expense_group_settings?.split_expense_grouping)
- The form control is properly mapped in the payload construction:
split_expense_grouping: exportSettingsForm.get('splitExpenseGrouping')?.value ? exportSettingsForm.get('splitExpenseGrouping')?.value : SplitExpenseGrouping.MULTIPLE_LINE_ITEM
- The UI component has proper form bindings and validation setup:
[mandatoryErrorListName]="'split expense grouping'"
[formControllerName]="'splitExpenseGrouping'"
Split expense grouping feature is properly integrated with form controls and validation.
The code shows complete integration with:
- Form initialization via
FormControl
- Default value handling in payload construction
- Proper UI validation and form bindings
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check integration points for split expense grouping
# Check form control initialization
ast-grep --pattern 'mapAPIResponseToFormGroup($response) {
$$$
}'
# Check validation rules setup
ast-grep --pattern 'getValidators() {
$$$
}'
# Look for any split expense grouping related validation or watcher setup
rg "split.*expense.*group" -A 5
Length of output: 21900
71-71
: LGTM! The readonly property follows component's patterns.
The addition of splitExpenseGroupingOptions
as a readonly property aligns with the component's pattern for option properties.
Let's verify the integration of this new option with form controls:
✅ Verification successful
Based on the search results, I can see that:
- The
splitExpenseGrouping
form control is properly integrated in the NetSuite export settings model (src/app/core/models/netsuite/netsuite-configuration/netsuite-export-setting.model.ts
). - The form control is initialized with the value from
exportSettings?.expense_group_settings?.split_expense_grouping
. - The component's template (
netsuite-export-settings.component.html
) correctly uses this property in a configuration select field. - The feature is conditionally rendered based on
brandingFeatureConfig.featureFlags.exportSettings.splitExpenseGrouping
. - The form control is properly included in the credit card expense form group.
The readonly property is properly integrated with form controls and follows the component's patterns.
- The form control is correctly initialized in the model
- The template properly renders the select field with the options
- The feature flag controls the visibility as expected
- The form control is included in the appropriate form group
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check if splitExpenseGrouping is properly integrated in the form setup
# and if there are any missing form control initializations.
# Look for splitExpenseGrouping related form control setup
rg -A 5 "splitExpenseGrouping"
# Check the model's getSplitExpenseGroupingOptions implementation
ast-grep --pattern 'getSplitExpenseGroupingOptions() {
$$$
}'
Length of output: 31431
71-71
: Verify error handling for split expense grouping.
Ensure proper error handling is in place for:
- Invalid split expense grouping selections
- Inclusion of split expense grouping in the payload construction
Let's verify the error handling:
✅ Verification successful
Let me gather more information about the split expense grouping validation and payload construction:
Let me gather one final piece of information about the validation setup:
Based on the gathered information, I can now provide the final response:
Split expense grouping validation is properly implemented
The code analysis shows that:
- Split expense grouping is included in the validator rules for credit card expenses (
creditCardExpense
array inexportSettingValidatorRule
) - Form validation is set up through
setConfigurationSettingValidatorsAndWatchers
- The field is properly handled in payload construction with a default fallback to
MULTIPLE_LINE_ITEM
- The UI enforces mandatory field validation through
[isFieldMandatory]="true"
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check error handling for split expense grouping
# Check payload construction
ast-grep --pattern 'constructPayload($form) {
$$$
}'
# Look for validation error messages
rg "split.*expense.*error" -A 5
# Check form validation setup
rg "setConfigurationSettingValidatorsAndWatchers" -A 10
Length of output: 40510
Script:
#!/bin/bash
# Check for split expense grouping related code
# Look for split expense grouping model and validation
ast-grep --pattern 'class NetSuiteExportSettingModel {
$$$
getSplitExpenseGroupingOptions() {
$$$
}
$$$
}'
# Check for split expense grouping in payload construction
ast-grep --pattern 'constructPayloadAndSave() {
$$$
}'
# Look for any validation related to split expense grouping
rg "splitExpenseGrouping" -A 3
Length of output: 22261
Script:
#!/bin/bash
# Check validation setup for split expense grouping
# Look for validation setup in NetSuite export settings model
ast-grep --pattern 'class NetSuiteExportSettingModel {
$$$
static getValidators() {
$$$
}
$$$
}'
# Check for any error messages related to split expense grouping
rg "split.*expense.*error" -A 3
# Look for form validation setup in the component
rg "exportSettingValidatorRule" -A 5
Length of output: 23323
src/app/integrations/netsuite/netsuite-shared/netsuite-export-settings/netsuite-export-settings.component.html (2)
318-330
: LGTM! The implementation follows established patterns.
The new split expense grouping configuration field:
- Correctly uses feature flag for conditional rendering
- Follows the same component structure as other fields
- Maintains UI/UX consistency with proper labeling and validation
However, let's verify the feature flag implementation:
✅ Verification successful
Feature flag implementation is consistent across integrations
The verification shows that:
- The feature flag is properly defined in the branding configuration models
- It's consistently used across all integrations (NetSuite, Xero, QBO, Intacct) with the same pattern
- The form control and default values are properly handled in respective export setting models
- The UI implementation follows the same pattern across all integration components
The implementation in the NetSuite component aligns perfectly with the established patterns in other integrations, maintaining consistency in:
- Feature flag usage
- Form control integration
- UI component structure
- Default value handling (MULTIPLE_LINE_ITEM)
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify the feature flag implementation across the codebase
# Expected: The feature flag should be defined in the configuration and used consistently
# Check feature flag definition
rg -A 5 "splitExpenseGrouping.*featureFlags"
# Check all usages of the feature flag
rg "splitExpenseGrouping"
Length of output: 7718
319-329
: Form validation is properly implemented.
The configuration field:
- Is correctly integrated with the reactive form
- Has proper validation setup
- Provides clear error messaging
Let's verify the form control initialization:
✅ Verification successful
Form validation is properly implemented for split expense grouping field
The form control splitExpenseGrouping
is:
- Correctly initialized in the model's
mapAPIResponseToFormGroup
- Included in the validation rules under
creditCardExpense
group - Properly integrated with the form validation flow through
addExportSettingFormValidator
The evidence shows that:
- The form control is initialized with proper binding to the API response
- The field is part of the credit card expense validation group, which is appropriate for split expense grouping
- The helper service sets up proper validation through
addExportSettingFormValidator
- The component properly initializes and sets up the validators through
setConfigurationSettingValidatorsAndWatchers
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify the form control initialization in the component
# Expected: The form control should be properly initialized with validation
# Check form initialization
ast-grep --pattern 'splitExpenseGrouping = new FormControl'
# Check validation setup
rg "splitExpenseGrouping.*Validators"
Length of output: 101
Script:
#!/bin/bash
# Let's try a broader search for the form initialization and validation
# Search for the component file
fd "netsuite-export-settings.component.ts$"
# Look for form initialization patterns
rg -A 5 "exportSettingForm.*FormGroup"
# Search for any form control initialization
rg -A 3 "FormControl\("
# Look for validation patterns in the component
rg "Validators\."
Length of output: 113120
Script:
#!/bin/bash
# Let's check the form initialization and validation in the NetSuite export settings component
# Find the form initialization in the component
rg -A 10 "splitExpenseGrouping.*FormControl" src/app/integrations/netsuite/netsuite-shared/netsuite-export-settings/netsuite-export-settings.component.ts
# Look for form validation setup
rg -A 5 "addExportSettingFormValidator" src/app/integrations/netsuite/netsuite-shared/netsuite-export-settings/netsuite-export-settings.component.ts
# Check for any validation rules in the model
rg -A 5 "getValidators" src/app/integrations/netsuite/netsuite-shared/netsuite-export-settings/netsuite-export-settings.component.ts
Length of output: 1578
Script:
#!/bin/bash
# Let's check the model for form initialization and validation
# Look for the model file and its form initialization
rg -A 10 "mapAPIResponseToFormGroup" src/app/core/models/netsuite/netsuite-configuration/netsuite-export-setting.model.ts
# Check for validation setup in the model
rg -A 10 "getValidators" src/app/core/models/netsuite/netsuite-configuration/netsuite-export-setting.model.ts
# Look for helper service validation setup
rg -A 5 "addExportSettingFormValidator" src/app/core/services/common/helper.service.ts
Length of output: 2531
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (7)
src/app/core/models/netsuite/netsuite-configuration/netsuite-export-setting.model.ts (1)
310-311
: Consider refactoring the default value handlingThe default value
SplitExpenseGrouping.MULTIPLE_LINE_ITEM
is hardcoded in the payload construction. Consider:
- Moving this to a class constant for better maintainability
- Fixing the indentation to match the surrounding code
+ private static readonly DEFAULT_SPLIT_EXPENSE_GROUPING = SplitExpenseGrouping.MULTIPLE_LINE_ITEM; static constructPayload(exportSettingsForm: FormGroup): NetSuiteExportSettingPost { // ... expense_group_settings: { // ... - ccc_export_date_type: exportSettingsForm.get('creditCardExportDate')?.value, - split_expense_grouping: exportSettingsForm.get('splitExpenseGrouping')?.value ? exportSettingsForm.get('splitExpenseGrouping')?.value : SplitExpenseGrouping.MULTIPLE_LINE_ITEM + ccc_export_date_type: exportSettingsForm.get('creditCardExportDate')?.value, + split_expense_grouping: exportSettingsForm.get('splitExpenseGrouping')?.value ?? NetSuiteExportSettingModel.DEFAULT_SPLIT_EXPENSE_GROUPING },src/app/integrations/netsuite/netsuite-shared/netsuite-export-settings/netsuite-export-settings.component.ts (4)
Line range hint
496-583
: Consider breaking down the form setup logicThe
getSettingsAndSetupForm()
method is handling multiple responsibilities:
- Fetching export settings
- Processing destination attributes
- Setting up form controls
- Configuring validators
- Setting up watchers
Consider breaking this down into smaller, focused methods for better maintainability and testability.
Example refactor:
private setupFormControls(): void { this.exportSettingForm = NetSuiteExportSettingModel.mapAPIResponseToFormGroup(this.exportSettings); if (!this.brandingFeatureConfig.featureFlags.exportSettings.reimbursableExpenses) { this.exportSettingForm.controls.creditCardExpense.patchValue(true); } } private setupValidators(): void { this.helperService.addExportSettingFormValidator(this.exportSettingForm); const [exportSettingValidatorRule, exportModuleRule] = NetSuiteExportSettingModel.getValidators(); this.helperService.setConfigurationSettingValidatorsAndWatchers(exportSettingValidatorRule, this.exportSettingForm); // ... rest of validator setup } private async getSettingsAndSetupForm(): void { this.isOnboarding = this.windowReference.location.pathname.includes('onboarding'); await this.fetchExportSettings(); this.setupFormControls(); this.setupValidators(); this.setupWatchers(); this.isLoading = false; }
Line range hint
585-587
: Add subscription cleanup to prevent memory leaksThe component creates multiple subscriptions but doesn't implement
OnDestroy
to clean them up. This could lead to memory leaks, especially when navigating between routes.Add subscription cleanup:
export class NetsuiteExportSettingsComponent implements OnInit, OnDestroy { private destroy$ = new Subject<void>(); // Update existing subscriptions to use takeUntil private setupCustomWatchers(): void { this.exportSettingService.creditCardExportTypeChange .pipe(takeUntil(this.destroy$)) .subscribe((selectedValue: NetSuiteCorporateCreditCardExpensesObject) => { // ... existing logic }); } ngOnDestroy(): void { this.destroy$.next(); this.destroy$.complete(); this.optionSearchUpdate.complete(); } }
Line range hint
249-262
: Enhance error handling with specific error messagesThe error handling in the save operation uses a generic error message. Consider capturing and displaying more specific error information to help users understand and resolve issues.
}, (error) => { this.isSaveInProgress = false; const errorMessage = error.error?.message || 'Error saving export settings, please try again later'; this.toastService.displayToastMessage(ToastSeverity.ERROR, errorMessage); });
Line range hint
33-45
: Consider using an enum for component state managementThe component uses multiple boolean flags for state management. Consider using an enum to make the state management more maintainable and prevent invalid states.
enum ComponentState { Loading = 'loading', Saving = 'saving', Ready = 'ready', Error = 'error' } export class NetsuiteExportSettingsComponent implements OnInit { currentState: ComponentState = ComponentState.Loading; get isLoading(): boolean { return this.currentState === ComponentState.Loading; } get isSaving(): boolean { return this.currentState === ComponentState.Saving; } }src/app/integrations/netsuite/netsuite-shared/netsuite-export-settings/netsuite-export-settings.component.html (2)
324-324
: Enhance the subLabel to be more descriptive.The current subLabel could be more helpful by explaining what split expenses are and the implications of different grouping options.
- [subLabel]="'Choose how expenses should be grouped for split expenses'" + [subLabel]="'Choose how to group expenses that have been split across multiple cost centers, departments, or projects. This affects how the split portions appear in NetSuite.'"
318-330
: Consider moving this field closer to the related expense grouping field.The split expense grouping configuration is logically related to the general expense grouping configuration above. Consider moving this field immediately after the general expense grouping field to maintain better logical grouping of related settings.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (4)
src/app/core/models/db/expense-group-setting.model.ts
(1 hunks)src/app/core/models/netsuite/netsuite-configuration/netsuite-export-setting.model.ts
(4 hunks)src/app/integrations/netsuite/netsuite-shared/netsuite-export-settings/netsuite-export-settings.component.html
(1 hunks)src/app/integrations/netsuite/netsuite-shared/netsuite-export-settings/netsuite-export-settings.component.ts
(1 hunks)
🔇 Additional comments (7)
src/app/core/models/db/expense-group-setting.model.ts (2)
Line range hint 1-1
: Verify the SplitExpenseGrouping enum exists
Let's ensure the newly imported enum is properly defined.
✅ Verification successful
The SplitExpenseGrouping enum is properly defined and exported
The enum is correctly defined in src/app/core/models/enum/enum.model.ts
with two values:
SINGLE_LINE_ITEM
MULTIPLE_LINE_ITEM
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify the SplitExpenseGrouping enum definition
# Expected: Should find the enum definition in enum.model.ts
# Search for the enum definition
ast-grep --pattern 'export enum SplitExpenseGrouping {
$$$
}'
# Backup: Search using ripgrep in case the file structure is different
rg -p "enum SplitExpenseGrouping" -g "*.ts"
Length of output: 483
10-10
:
Consider making split_expense_grouping optional for backward compatibility
The new property is added as required, which could break existing implementations. Consider making it optional with a default value to ensure backward compatibility.
Apply this diff to make the property optional:
- split_expense_grouping: SplitExpenseGrouping;
+ split_expense_grouping?: SplitExpenseGrouping;
Additionally, ensure that:
- Default values are handled in the business logic
- Existing expense groups are migrated if necessary
src/app/core/models/netsuite/netsuite-configuration/netsuite-export-setting.model.ts (3)
6-6
: LGTM: Import statement is correctly updated
The addition of SplitExpenseGrouping
to the imports is appropriate and necessary for the new split expense grouping functionality.
289-290
: LGTM: Form control addition is correct
The new form control for splitExpenseGrouping
is properly added and correctly maps to the API response.
240-240
: Consider adding validation rules for splitExpenseGrouping
While splitExpenseGrouping
is added to the required fields, there are no corresponding validation rules in the exportModuleRule
array. Consider if certain creditCardExportType
values require specific splitExpenseGrouping
values.
Let's check if there are any dependencies between these fields:
src/app/integrations/netsuite/netsuite-shared/netsuite-export-settings/netsuite-export-settings.component.ts (1)
71-72
: Verify the integration of splitExpenseGroupingOptions
The new property is added but appears to be unused in the component. Please ensure that:
- The property is integrated with form controls
- The template utilizes this property for split expense grouping selection
- The form validation includes this new option
✅ Verification successful
Property is properly integrated and used in the component
The splitExpenseGroupingOptions
property is correctly integrated in the component:
- It's used in the template with
app-configuration-select-field
component - The form control name 'splitExpenseGrouping' is properly set
- The property provides options from the base model's
getSplitExpenseGroupingOptions()
method which returns valid select options
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if the property is used in the template
rg -l "splitExpenseGroupingOptions" --type html
# Check if there are any form controls using this property
rg "splitExpenseGrouping" --type typescript -A 5 "mapAPIResponseToFormGroup|FormGroup|FormControl"
Length of output: 775
Script:
#!/bin/bash
# Check if the property is used in the template with proper context
rg "splitExpenseGroupingOptions" -A 5 -B 5 src/app/integrations/netsuite/netsuite-shared/netsuite-export-settings/netsuite-export-settings.component.html
# Check form controls and property usage in the component
rg "splitExpenseGrouping" -A 5 -B 5 src/app/integrations/netsuite/netsuite-shared/netsuite-export-settings/netsuite-export-settings.component.ts
# Check the model class for context
rg "getSplitExpenseGroupingOptions" -A 5 -B 5
Length of output: 11948
src/app/integrations/netsuite/netsuite-shared/netsuite-export-settings/netsuite-export-settings.component.html (1)
318-330
: LGTM! The implementation follows consistent patterns.
The new split expense grouping field is well-integrated into the existing form structure, with proper:
- Conditional rendering based on feature flag and export type
- Mandatory field validation
- Consistent styling and component usage
Let's verify the feature flag usage:
✅ Verification successful
Feature flag is properly defined and used
The implementation correctly uses the splitExpenseGrouping
feature flag:
- The flag is properly defined in the feature configuration model:
exportSettings: {
...
splitExpenseGrouping: boolean;
}
- It's correctly configured in both branding configs:
- Fyle:
splitExpenseGrouping: true
- C1:
splitExpenseGrouping: false
- The component's template correctly uses the flag in the conditional rendering:
*ngIf="brandingFeatureConfig.featureFlags.exportSettings.splitExpenseGrouping"
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify the feature flag definition and usage
# Expected: The feature flag should be defined in the configuration
# Search for the feature flag definition
rg -A 2 "splitExpenseGrouping.*featureFlags"
# Search for other usages of this feature flag
rg "splitExpenseGrouping.*featureFlags"
Length of output: 88
Script:
#!/bin/bash
# Let's try different search patterns to locate the feature flag definition and usage
# Search for splitExpenseGrouping in feature flags or configuration
rg -i "splitExpenseGrouping"
# Search specifically in feature configuration files
fd -e ts -e json "feature|config" --exec rg -l "splitExpenseGrouping" {}
# Search in the component file for the feature flag usage
fd "netsuite-export-settings.component.ts" --exec cat {}
Length of output: 38429
Script:
#!/bin/bash
# Let's check the feature flag definition in branding config files and its usage in the component
# Search for feature flag definition in branding config
fd -e ts "branding-config" --exec cat {}
# Search for the feature flag interface definition
fd "feature-configuration.model.ts" --exec cat {}
Length of output: 24861
|
* feat: support split expense grouping for Netsuite * refactor: remove comment (cherry picked from commit 92dc51b)
Clickup
https://app.clickup.com/t/86cx0vkh9
Summary by CodeRabbit
New Features
Bug Fixes
Documentation
Refactor