-
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: move employee settings to export settings #1115
Conversation
WalkthroughThe changes in this pull request involve modifications to the routing configuration and component structure of the QBO integration module. Specifically, the route for Changes
Possibly related PRs
Suggested labels
Suggested reviewers
Poem
🪧 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 (3)
src/app/integrations/qbo/qbo-shared/qbo-export-settings/qbo-export-settings.component.ts (3)
121-122
: Fix formatting issues in comment and remove trailing spacesLine 121 has trailing spaces, and the comment on line 122 is missing a space after
//
. This adjustment enhances code readability and adheres to style guidelines.Apply this diff to fix the issues:
- -//Employee settings +// Employee settings🧰 Tools
🪛 eslint
[error] 121-121: Trailing spaces not allowed.
(no-trailing-spaces)
[error] 122-122: Expected space or tab after '//' in comment.
(spaced-comment)
124-128
: Add blank lines between class members for readabilityAdding blank lines between class members improves readability and complies with style guidelines indicated by the linter.
Apply this diff to add blank lines:
employeeSettingForm: FormGroup; + employeeMappingOptions: SelectFormOption[] = EmployeeSettingModel.getEmployeeFieldMappingOptions(); + autoMapEmployeeOptions: SelectFormOption[] = QBOEmployeeSettingModel.getAutoMapEmployeeOptions(); + employeeSetting: QBOEmployeeSettingGet; + existingEmployeeFieldMapping: EmployeeFieldMapping;🧰 Tools
🪛 eslint
[error] 124-124: Expected blank line between class members.
(lines-between-class-members)
[error] 125-125: Expected blank line between class members.
(lines-between-class-members)
[error] 126-126: Expected blank line between class members.
(lines-between-class-members)
[error] 127-127: Expected blank line between class members.
(lines-between-class-members)
[error] 128-128: Expected blank line between class members.
(lines-between-class-members)
436-436
: Remove unexpected trailing commaLine 436 has an unexpected trailing comma, which may lead to syntax errors or unintended behavior.
Apply this diff to fix the issue:
- ...groupedAttributes, + ...groupedAttributes🧰 Tools
🪛 eslint
[error] 436-436: Unexpected trailing comma.
(comma-dangle)
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
src/app/integrations/qbo/qbo-shared/qbo-export-settings/qbo-export-settings.component.html
(1 hunks)src/app/integrations/qbo/qbo-shared/qbo-export-settings/qbo-export-settings.component.ts
(7 hunks)
🧰 Additional context used
🪛 eslint
src/app/integrations/qbo/qbo-shared/qbo-export-settings/qbo-export-settings.component.ts
[error] 121-121: Trailing spaces not allowed.
(no-trailing-spaces)
[error] 122-122: Expected space or tab after '//' in comment.
(spaced-comment)
[error] 124-124: Expected blank line between class members.
(lines-between-class-members)
[error] 125-125: Expected blank line between class members.
(lines-between-class-members)
[error] 126-126: Expected blank line between class members.
(lines-between-class-members)
[error] 127-127: Expected blank line between class members.
(lines-between-class-members)
[error] 128-128: Expected blank line between class members.
(lines-between-class-members)
[error] 436-436: Unexpected trailing comma.
(comma-dangle)
🔇 Additional comments (2)
src/app/integrations/qbo/qbo-shared/qbo-export-settings/qbo-export-settings.component.ts (1)
440-441
:
Verify the structure of employeeSettings
for correct property access
It appears that employeeSettings
may not have a workspace_general_settings
property. The properties employee_field_mapping
and auto_map_employees
might need to be accessed directly from employeeSettings
.
Run the following script to verify the structure of QBOEmployeeSettingGet
:
Also applies to: 455-457
src/app/integrations/qbo/qbo-shared/qbo-export-settings/qbo-export-settings.component.html (1)
15-36
: Integrate employee settings form correctly
The addition of the employeeSettingForm
is well-implemented, and the form controls are properly configured with the necessary bindings and validations.
src/app/integrations/qbo/qbo-shared/qbo-export-settings/qbo-export-settings.component.ts
Outdated
Show resolved
Hide resolved
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 (2)
src/app/integrations/qbo/qbo-shared/qbo-export-settings/qbo-export-settings.component.ts (2)
122-133
: Consider grouping related propertiesThe employee settings related properties are scattered. Consider grouping them together using a private interface or type to improve code organization and maintainability.
+interface EmployeeSettingsState { + form: FormGroup; + mappingOptions: SelectFormOption[]; + autoMapOptions: SelectFormOption[]; + settings: QBOEmployeeSettingGet; + existingFieldMapping: EmployeeFieldMapping; + liveEntityExample: {[FyleField.EMPLOYEE]: string | undefined, [FyleField.VENDOR]: string | undefined}; +} + +private employeeSettings: EmployeeSettingsState; -employeeSettingForm: FormGroup; -employeeMappingOptions: SelectFormOption[]; -autoMapEmployeeOptions: SelectFormOption[]; -employeeSetting: QBOEmployeeSettingGet; -existingEmployeeFieldMapping: EmployeeFieldMapping; -liveEntityExample: {[FyleField.EMPLOYEE]: string | undefined, [FyleField.VENDOR]: string | undefined};
160-160
: Consider more specific error handlingThe success and error messages are too generic. Consider providing more context about which operation failed (employee settings or export settings).
-this.toastService.displayToastMessage(ToastSeverity.SUCCESS, 'Settings saved successfully'); +this.toastService.displayToastMessage(ToastSeverity.SUCCESS, 'Employee and export settings saved successfully'); -this.toastService.displayToastMessage(ToastSeverity.ERROR, 'Error saving settings, please try again later'); +this.toastService.displayToastMessage(ToastSeverity.ERROR, 'Error saving employee and export settings, please try again later');Also applies to: 167-167
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
src/app/integrations/qbo/qbo-shared/qbo-export-settings/qbo-export-settings.component.html
(1 hunks)src/app/integrations/qbo/qbo-shared/qbo-export-settings/qbo-export-settings.component.ts
(7 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- src/app/integrations/qbo/qbo-shared/qbo-export-settings/qbo-export-settings.component.html
🔇 Additional comments (5)
src/app/integrations/qbo/qbo-shared/qbo-export-settings/qbo-export-settings.component.ts (5)
19-22
: LGTM: Clean import statements
The new imports for employee settings models and services are properly organized and follow the existing pattern.
154-158
: LGTM: Proper use of forkJoin for parallel API calls
The save functionality correctly uses forkJoin
to handle both employee and export settings updates in parallel.
172-177
: LGTM: Well-structured helper method
The setLiveEntityExample
method is well-structured and properly handles the mapping of employee and vendor attributes.
439-442
: LGTM: Proper use of forkJoin for initialization
The initialization logic correctly uses forkJoin
to fetch all required data in parallel, including the new employee settings data.
460-464
:
Verify initialization of existingEmployeeFieldMapping
The form control employeeMapping
is initialized with this.existingEmployeeFieldMapping
, but there's no clear initialization of this property before its usage.
Apply this diff to ensure proper initialization:
this.employeeFieldMapping = employeeSettings.workspace_general_settings.employee_field_mapping;
+this.existingEmployeeFieldMapping = this.employeeFieldMapping;
this.employeeSettingForm = new FormGroup({
employeeMapping: new FormControl(this.existingEmployeeFieldMapping, Validators.required),
autoMapEmployee: new FormControl(employeeSettings.workspace_general_settings?.auto_map_employees),
searchOption: new FormControl('')
});
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/integrations/qbo/qbo-shared/qbo-export-settings/qbo-export-settings.component.html (2)
104-104
: Consider extracting complex condition into a component propertyThe condition for showing the accounts payable field is complex and appears in multiple places. Consider extracting it to improve readability and maintainability.
In the component class:
get shouldShowAccountsPayable(): boolean { return this.exportSettingForm.controls.reimbursableExportType.value === QBOReimbursableExpensesObject.BILL || (this.exportSettingForm.controls.reimbursableExportType.value === QBOReimbursableExpensesObject.JOURNAL_ENTRY && this.exportSettingForm.get('employeeMapping')?.value === EmployeeFieldMapping.VENDOR); }In the template:
-<div *ngIf="(exportSettingForm.controls.reimbursableExportType.value === QBOReimbursableExpensesObject.BILL || (exportSettingForm.controls.reimbursableExportType.value === QBOReimbursableExpensesObject.JOURNAL_ENTRY && exportSettingForm.get('employeeMapping')?.value === EmployeeFieldMapping.VENDOR))"> +<div *ngIf="shouldShowAccountsPayable">
126-126
: Consider updating the placeholder text for clarityThe placeholder "Select representation" for the auto-map field could be more specific to help users understand what they're selecting.
-[placeholder]="'Select representation'" +[placeholder]="'Select auto-mapping parameter'"
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (5)
src/app/integrations/qbo/qbo-shared/qbo-employee-settings/qbo-employee-settings.component.html
(0 hunks)src/app/integrations/qbo/qbo-shared/qbo-employee-settings/qbo-employee-settings.component.spec.ts
(0 hunks)src/app/integrations/qbo/qbo-shared/qbo-employee-settings/qbo-employee-settings.component.ts
(0 hunks)src/app/integrations/qbo/qbo-shared/qbo-export-settings/qbo-export-settings.component.html
(1 hunks)src/app/integrations/qbo/qbo-shared/qbo-shared.module.ts
(0 hunks)
💤 Files with no reviewable changes (4)
- src/app/integrations/qbo/qbo-shared/qbo-shared.module.ts
- src/app/integrations/qbo/qbo-shared/qbo-employee-settings/qbo-employee-settings.component.spec.ts
- src/app/integrations/qbo/qbo-shared/qbo-employee-settings/qbo-employee-settings.component.ts
- src/app/integrations/qbo/qbo-shared/qbo-employee-settings/qbo-employee-settings.component.html
🔇 Additional comments (1)
src/app/integrations/qbo/qbo-shared/qbo-export-settings/qbo-export-settings.component.html (1)
107-128
: LGTM! Form validation and data binding are well implemented
The employee mapping fields are properly implemented with:
- Correct form binding
- Proper validation attributes
- Clear error messages
- Consistent mandatory field handling
src/app/integrations/qbo/qbo-shared/qbo-export-settings/qbo-export-settings.component.html
Outdated
Show resolved
Hide resolved
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/integrations/qbo/qbo-shared/qbo-export-settings/qbo-export-settings.component.spec.ts (2)
118-126
: Consider using TypeScript's strict type checkingThe workspace_id is explicitly typed as a number (line 124), but the initialization shows inconsistency with the type system.
- workspace_id: 0 // Changed from string to number + workspace_id: 0 // Type enforced by interface
79-79
: Fix trailing whitespace issuesMultiple lines contain trailing whitespace which should be removed to maintain code cleanliness.
Remove trailing spaces from lines 79, 82, 98, 99, 426, 453, 457, 460, and 464.
Also applies to: 82-82, 98-98, 99-99, 426-426, 453-453, 457-457, 460-460, 464-464
🧰 Tools
🪛 eslint
[error] 79-79: Trailing spaces not allowed.
(no-trailing-spaces)
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
src/app/integrations/qbo/qbo-shared/qbo-export-settings/qbo-export-settings.component.spec.ts
(7 hunks)src/app/integrations/qbo/qbo.fixture.ts
(1 hunks)
🧰 Additional context used
🪛 eslint
src/app/integrations/qbo/qbo-shared/qbo-export-settings/qbo-export-settings.component.spec.ts
[error] 79-79: Trailing spaces not allowed.
(no-trailing-spaces)
[error] 82-82: Trailing spaces not allowed.
(no-trailing-spaces)
[error] 98-98: Trailing spaces not allowed.
(no-trailing-spaces)
[error] 99-99: Trailing spaces not allowed.
(no-trailing-spaces)
[error] 426-426: Trailing spaces not allowed.
(no-trailing-spaces)
[error] 453-453: Trailing spaces not allowed.
(no-trailing-spaces)
[error] 457-457: Trailing spaces not allowed.
(no-trailing-spaces)
[error] 460-460: Trailing spaces not allowed.
(no-trailing-spaces)
[error] 464-464: Trailing spaces not allowed.
(no-trailing-spaces)
🔇 Additional comments (6)
src/app/integrations/qbo/qbo-shared/qbo-export-settings/qbo-export-settings.component.spec.ts (4)
8-8
: LGTM: HttpClientTestingModule import added correctly
The addition of HttpClientTestingModule is appropriate for testing components that make HTTP requests.
Also applies to: 82-85
97-104
: LGTM: QboEmployeeSettingsService provider setup
The service is properly configured with the required mock methods for employee settings functionality.
🧰 Tools
🪛 eslint
[error] 98-98: Trailing spaces not allowed.
(no-trailing-spaces)
[error] 99-99: Trailing spaces not allowed.
(no-trailing-spaces)
427-445
: LGTM: Comprehensive form initialization
The form initialization covers all required fields with appropriate mock values for testing.
448-451
: LGTM: Employee settings form initialization
The employee settings form is properly initialized with the required fields.
src/app/integrations/qbo/qbo.fixture.ts (2)
343-343
: LGTM! The employee field mapping change aligns with PR objectives.
The change from VENDOR
to EMPLOYEE
in mockWorkspaceGeneralSettings
correctly reflects the migration of employee settings to export settings.
Line range hint 1-1000
: Verify mock data consistency across test scenarios.
The mock data structure is comprehensive, but we should verify that all test scenarios using this fixture will work correctly with the updated employee field mapping.
✅ Verification successful
Let me analyze the test files to understand the impact of employee field mapping changes.
Based on the analysis of the test files, I can now provide a final response:
Mock data in qbo.fixture.ts is intentionally using both VENDOR and EMPLOYEE mappings for different test scenarios
The mock data variations in the fixture file are actually correct and necessary because:
- The test files explicitly verify different employee field mapping scenarios (VENDOR vs EMPLOYEE)
- QBO advanced settings component has specific test cases checking behavior when
employee_field_mapping
is VENDOR vs EMPLOYEE - Base mapping component tests verify the correct field mapping resolution for both cases
- Clone settings component needs both mappings to test the visibility logic of vendor-related fields
The apparent inconsistency in the mock data is intentional to support various test cases that validate the application's behavior with different employee field mapping configurations.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for any hardcoded references to VENDOR mapping in test files
# that might need to be updated to match the new EMPLOYEE mapping
# Search for test files that might be affected by the employee field mapping change
rg -l "EmployeeFieldMapping.VENDOR" --type ts
# Look for any potential test assertions that might need updating
rg "employee_field_mapping.*VENDOR" --type ts
Length of output: 3769
Script:
#!/bin/bash
# Check the actual test assertions and mock data usage in the affected files
# Check QBO advanced settings tests
rg -A 5 -B 5 "employee_field_mapping.*VENDOR" src/app/integrations/qbo/qbo-shared/qbo-advanced-settings/qbo-advanced-settings.component.spec.ts
# Check clone settings component
rg -A 5 -B 5 "employee_field_mapping.*VENDOR" src/app/integrations/qbo/qbo-onboarding/qbo-clone-settings/qbo-clone-settings.component.ts
# Check base mapping component tests
rg -A 5 -B 5 "employee_field_mapping.*VENDOR" src/app/integrations/qbo/qbo-main/qbo-mapping/qbo-base-mapping/qbo-base-mapping.component.spec.ts
# Check the fixture usage in test files
rg "mockEmployeeSettingPayload" --type ts
Length of output: 3296
src/app/integrations/qbo/qbo-shared/qbo-export-settings/qbo-export-settings.component.spec.ts
Outdated
Show resolved
Hide resolved
src/app/integrations/qbo/qbo-shared/qbo-export-settings/qbo-export-settings.component.html
Outdated
Show resolved
Hide resolved
src/app/integrations/qbo/qbo-shared/qbo-export-settings/qbo-export-settings.component.ts
Outdated
Show resolved
Hide resolved
src/app/integrations/qbo/qbo-shared/qbo-export-settings/qbo-export-settings.component.ts
Outdated
Show resolved
Hide resolved
src/app/integrations/qbo/qbo-shared/qbo-export-settings/qbo-export-settings.component.ts
Outdated
Show resolved
Hide resolved
src/app/integrations/qbo/qbo-shared/qbo-export-settings/qbo-export-settings.component.ts
Outdated
Show resolved
Hide resolved
src/app/integrations/qbo/qbo-shared/qbo-export-settings/qbo-export-settings.component.ts
Outdated
Show resolved
Hide resolved
src/app/integrations/qbo/qbo-shared/qbo-export-settings/qbo-export-settings.component.ts
Outdated
Show resolved
Hide resolved
src/app/integrations/qbo/qbo-shared/qbo-export-settings/qbo-export-settings.component.ts
Outdated
Show resolved
Hide resolved
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
♻️ Duplicate comments (2)
src/app/integrations/qbo/qbo-shared/qbo-export-settings/qbo-export-settings.component.ts (1)
467-467
:⚠️ Potential issueInitialize
existingEmployeeFieldMapping
before using itThe form control
employeeMapping
is initialized withthis.existingEmployeeFieldMapping
, which may not have been assigned a value. This could lead toundefined
values in the form control.Apply this diff to initialize
existingEmployeeFieldMapping
properly:+ this.existingEmployeeFieldMapping = this.employeeFieldMapping; employeeMapping: new FormControl(this.existingEmployeeFieldMapping, Validators.required),
src/app/integrations/qbo/qbo-shared/qbo-export-settings/qbo-export-settings.component.html (1)
106-129
:⚠️ Potential issueAvoid nesting forms to prevent unexpected behavior
Nesting
<form>
elements (employeeSettingForm
withinexportSettingForm
) can cause unexpected behavior in Angular's form handling. Angular does not support nested forms properly, which might lead to issues during form submission and validation.Consider refactoring to avoid nested forms. You can merge the
employeeSettingForm
controls into the parentexportSettingForm
as a nestedFormGroup
:
In your component TypeScript file, add
employeeSettingForm
as a childFormGroup
ofexportSettingForm
:this.exportSettingForm.addControl('employeeSettings', this.employeeSettingForm);In your template, use
[formGroupName]
to bind to the nestedFormGroup
:<form [formGroup]="exportSettingForm"> <div *ngIf="brandingConfig.brandId === 'fyle'" formGroupName="employeeSettings"> <!-- Employee setting fields --> </div> <!-- Other form fields --> </form>This approach avoids nesting forms while maintaining the logical grouping of your form controls.
🧹 Nitpick comments (1)
src/app/integrations/qbo/qbo-shared/qbo-export-settings/qbo-export-settings.component.ts (1)
155-155
: Remove trailing spaces to comply with code style guidelinesThere are trailing spaces at the end of this line, which violates the coding standards and may cause linting errors.
Apply this diff to remove trailing spaces:
- const employeeSettingPayload = QBOEmployeeSettingModel.constructPayload(this.employeeSettingForm); + const employeeSettingPayload = QBOEmployeeSettingModel.constructPayload(this.employeeSettingForm);🧰 Tools
🪛 eslint
[error] 155-155: Trailing spaces not allowed.
(no-trailing-spaces)
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
src/app/core/models/common/advanced-settings.model.ts
(1 hunks)src/app/integrations/qbo/qbo-shared/qbo-export-settings/qbo-export-settings.component.html
(1 hunks)src/app/integrations/qbo/qbo-shared/qbo-export-settings/qbo-export-settings.component.spec.ts
(7 hunks)src/app/integrations/qbo/qbo-shared/qbo-export-settings/qbo-export-settings.component.ts
(7 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- src/app/integrations/qbo/qbo-shared/qbo-export-settings/qbo-export-settings.component.spec.ts
🧰 Additional context used
🪛 eslint
src/app/integrations/qbo/qbo-shared/qbo-export-settings/qbo-export-settings.component.ts
[error] 155-155: Trailing spaces not allowed.
(no-trailing-spaces)
🔇 Additional comments (1)
src/app/core/models/common/advanced-settings.model.ts (1)
97-97
: Consistently exclude 'card_number' from memo options
The updated filtering ensures that 'card_number' is consistently excluded from the memo options, aligning with the application's requirements.
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: 3
🧹 Nitpick comments (2)
src/app/integrations/qbo/qbo-shared/qbo-export-settings/qbo-export-settings.component.ts (2)
122-133
: Consider grouping related properties using an interface.The employee settings related properties could be encapsulated within an interface to improve code organization and maintainability.
interface EmployeeSettingsState { form: FormGroup; mappingOptions: SelectFormOption[]; autoMapOptions: SelectFormOption[]; settings: QBOEmployeeSettingGet; existingFieldMapping: EmployeeFieldMapping; liveEntityExample: {[FyleField.EMPLOYEE]: string | undefined, [FyleField.VENDOR]: string | undefined}; }
444-452
: Consider using switchMap for dependent API calls.The forkJoin setup could be improved by using switchMap for the dependent API calls, which would provide better error handling and cancellation of stale requests.
// Example refactor this.exportSettingService.getExportSettings().pipe( switchMap(exportSetting => { this.exportSettings = exportSetting; return forkJoin({ workspaceSettings: this.workspaceService.getWorkspaceGeneralSettings(), employeeSettings: this.employeeSettingService.getEmployeeSettings(), destinationAttributes: this.employeeSettingService.getDistinctQBODestinationAttributes([FyleField.EMPLOYEE, FyleField.VENDOR]), // ... other API calls }); }) ).subscribe({ next: (response) => { // Handle response }, error: (error) => { this.isLoading = false; this.toastService.displayToastMessage(ToastSeverity.ERROR, 'Failed to load settings'); console.error('Load settings error:', error); } });
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
src/app/integrations/qbo/qbo-shared/qbo-export-settings/qbo-export-settings.component.ts
(7 hunks)
🔇 Additional comments (1)
src/app/integrations/qbo/qbo-shared/qbo-export-settings/qbo-export-settings.component.ts (1)
19-22
: LGTM! Clean import organization.
The new imports for employee settings models and services are properly organized and follow the existing import pattern.
src/app/integrations/qbo/qbo-shared/qbo-export-settings/qbo-export-settings.component.ts
Show resolved
Hide resolved
src/app/integrations/qbo/qbo-shared/qbo-export-settings/qbo-export-settings.component.ts
Show resolved
Hide resolved
src/app/integrations/qbo/qbo-shared/qbo-export-settings/qbo-export-settings.component.ts
Outdated
Show resolved
Hide resolved
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
🧹 Nitpick comments (5)
src/app/integrations/qbo/qbo-onboarding/qbo-onboarding-connector/qbo-onboarding-connector.component.ts (1)
148-148
: LGTM with a nitpick: Fix method name typoThe navigation path change is correct, but there's a typo in the method name
checkCloneSettingsAvailablity
(should becheckCloneSettingsAvailability
).- private checkCloneSettingsAvailablity(): void { + private checkCloneSettingsAvailability(): void {src/app/core/models/qbo/qbo-configuration/qbo-export-setting.model.ts (1)
304-311
: Add type safety to form controls.The form group creation could be improved with proper typing for better maintainability and type checking.
Consider this typed implementation:
-static createEmployeeSettingsForm(existingEmployeeFieldMapping: EmployeeFieldMapping, autoMapEmployees: boolean): FormGroup { +interface EmployeeSettingsForm { + employeeMapping: FormControl<EmployeeFieldMapping>; + autoMapEmployee: FormControl<boolean>; + searchOption: FormControl<string>; +} + +static createEmployeeSettingsForm( + existingEmployeeFieldMapping: EmployeeFieldMapping, + autoMapEmployees: boolean +): FormGroup<EmployeeSettingsForm> { return new FormGroup({ - employeeMapping: new FormControl(existingEmployeeFieldMapping, Validators.required), - autoMapEmployee: new FormControl(autoMapEmployees), - searchOption: new FormControl('') + employeeMapping: new FormControl(existingEmployeeFieldMapping, { + validators: [Validators.required], + nonNullable: true + }), + autoMapEmployee: new FormControl(autoMapEmployees, { nonNullable: true }), + searchOption: new FormControl('', { nonNullable: true }) }); }src/app/integrations/qbo/qbo-onboarding/qbo-clone-settings/qbo-clone-settings.component.ts (3)
Line range hint
1-824
: Consider splitting this large component for better maintainabilityThe component handles multiple complex forms and their interactions. Consider:
- Extracting form setup logic into separate services for each setting type
- Creating sub-components for each settings section
- Using a facade service to coordinate between different settings
This would improve:
- Code maintainability
- Testing capabilities
- Reusability
Line range hint
290-300
: Enhance error handling in save operationThe current error handling is basic. Consider:
- Adding specific error cases handling
- Providing more detailed error messages
- Implementing retry logic for transient failures
save(): void { this.isSaveInProgress = true; const cloneSettingPayload = QBOCloneSettingModel.constructPayload(this.employeeSettingForm, this.exportSettingForm, this.importSettingForm, this.advancedSettingForm, this.isTaxGroupSyncAllowed); this.cloneSettingService.postCloneSettings(cloneSettingPayload).subscribe((response) => { this.isSaveInProgress = false; this.toastService.displayToastMessage(ToastSeverity.SUCCESS, 'Cloned settings successfully'); this.router.navigate([`/integrations/qbo/onboarding/done`]); - }, () => { + }, (error) => { this.isSaveInProgress = false; - this.toastService.displayToastMessage(ToastSeverity.ERROR, 'Failed to clone settings'); + const errorMessage = error.error?.message || 'Failed to clone settings'; + this.toastService.displayToastMessage(ToastSeverity.ERROR, errorMessage); + // Add retry logic if needed }); }
Line range hint
466-486
: Improve form validation with typed forms and centralized rulesThe current validation setup is spread across multiple methods. Consider:
- Using typed reactive forms (available in Angular 14+)
- Centralizing validation rules in a separate configuration
- Adding meaningful validation error messages
Example for typed form implementation:
interface ImportSettingsForm { taxCode: FormControl<boolean>; defaultTaxCode: FormControl<string | null>; // ... other form controls } const importSettingForm = new FormGroup<ImportSettingsForm>({ taxCode: new FormControl(false), defaultTaxCode: new FormControl(null), // ... other form controls });
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (15)
src/app/core/models/enum/enum.model.ts
(0 hunks)src/app/core/models/qbo/qbo-configuration/qbo-export-setting.model.ts
(1 hunks)src/app/core/models/qbo/qbo-configuration/qbo-onboarding.model.ts
(1 hunks)src/app/integrations/qbo/qbo-onboarding/qbo-clone-settings/qbo-clone-settings.component.ts
(1 hunks)src/app/integrations/qbo/qbo-onboarding/qbo-onboarding-connector/qbo-onboarding-connector.component.ts
(3 hunks)src/app/integrations/qbo/qbo-onboarding/qbo-onboarding-employee-settings/qbo-onboarding-employee-settings.component.html
(0 hunks)src/app/integrations/qbo/qbo-onboarding/qbo-onboarding-employee-settings/qbo-onboarding-employee-settings.component.spec.ts
(0 hunks)src/app/integrations/qbo/qbo-onboarding/qbo-onboarding-employee-settings/qbo-onboarding-employee-settings.component.ts
(0 hunks)src/app/integrations/qbo/qbo-onboarding/qbo-onboarding-routing.module.ts
(0 hunks)src/app/integrations/qbo/qbo-onboarding/qbo-onboarding.module.ts
(0 hunks)src/app/integrations/qbo/qbo-shared/qbo-export-settings/qbo-export-settings.component.spec.ts
(8 hunks)src/app/integrations/qbo/qbo-shared/qbo-export-settings/qbo-export-settings.component.ts
(7 hunks)src/app/integrations/qbo/qbo.component.ts
(0 hunks)src/app/integrations/qbo/qbo.fixture.ts
(1 hunks)src/stories/SubMenu.stories.ts
(1 hunks)
💤 Files with no reviewable changes (7)
- src/app/core/models/enum/enum.model.ts
- src/app/integrations/qbo/qbo-onboarding/qbo-onboarding.module.ts
- src/app/integrations/qbo/qbo.component.ts
- src/app/integrations/qbo/qbo-onboarding/qbo-onboarding-routing.module.ts
- src/app/integrations/qbo/qbo-onboarding/qbo-onboarding-employee-settings/qbo-onboarding-employee-settings.component.html
- src/app/integrations/qbo/qbo-onboarding/qbo-onboarding-employee-settings/qbo-onboarding-employee-settings.component.spec.ts
- src/app/integrations/qbo/qbo-onboarding/qbo-onboarding-employee-settings/qbo-onboarding-employee-settings.component.ts
🚧 Files skipped from review as they are similar to previous changes (1)
- src/app/integrations/qbo/qbo-shared/qbo-export-settings/qbo-export-settings.component.spec.ts
🔇 Additional comments (13)
src/stories/SubMenu.stories.ts (2)
Line range hint 29-43
: LGTM! Story changes align with architectural updates
The story configuration correctly reflects the removal of the 'Map Employees' module and sets 'Export Settings' as the active module, maintaining consistency with the broader architectural changes of moving employee settings to export settings.
42-42
: Verify router paths consistency
Let's ensure the router paths in the story match the actual application routes, particularly after the employee settings reorganization.
✅ Verification successful
Router path is consistent with the application routes
The router path /integrations/qbo/main/configuration/export_settings
used in the story is valid and consistent with the actual application routes. The search results confirm:
- The path is correctly defined in QBO's configuration routing module (
qbo-main/qbo-configuration/qbo-configuration-routing.module.ts
) - It's consistently used across the application in:
- QBO configuration component's navigation menu
- QBO export settings component's navigation logic
- Other related components following the same pattern
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify router paths consistency across the codebase
# Search for route definitions in the routing modules
rg -t typescript "path.*export_settings|path.*import_settings|path.*advanced_settings" -A 3
# Search for routerLink usage in templates and components
rg -t typescript -t html "routerLink.*export_settings|routerLink.*import_settings|routerLink.*advanced_settings" -A 1
Length of output: 283
Script:
#!/bin/bash
# Search for route paths and routerLink usage without file type restrictions
rg "path:.*export_settings|path:.*import_settings|path:.*advanced_settings" -A 3
# Search for routerLink usage
rg "routerLink.*export_settings|routerLink.*import_settings|routerLink.*advanced_settings" -A 1
# Search for any mentions of these paths
rg "/integrations/qbo/main/configuration/(export_settings|import_settings|advanced_settings)" -A 1
Length of output: 33581
src/app/core/models/qbo/qbo-configuration/qbo-onboarding.model.ts (3)
Line range hint 76-78
: Review the step removal logic
The current implementation has a potential issue:
- The step removal logic
splice(1, 1)
assumes the employee settings step is at index 1 - Since the MAP_EMPLOYEES step has been removed from the model, this splice operation might remove the wrong step
Consider removing this conditional logic since the employee settings have been moved to export settings:
- if (!brandingFeatureConfig.featureFlags.mapEmployees) {
- this.onboardingSteps.splice(1, 1);
- }
If the feature flag is still needed, consider adding a comment explaining why it's retained and verify its usage:
✅ Verification successful
Let me gather more context about the onboarding steps to verify if the splice operation is indeed problematic.
Let me try a different approach to find the onboarding steps initialization.
Let me check the complete onboarding steps array to understand all the steps.
Remove the mapEmployees feature flag check and splice operation
The verification confirms that the splice operation is problematic because:
- The onboarding steps array shows that the second step (index 1) is now the Export Settings step
- The
splice(1, 1)
operation would incorrectly remove the Export Settings step instead of the intended Employee Settings step - Since the Employee Settings functionality has been moved to Export Settings (as mentioned in the review), there's no need to conditionally remove any step
- Remove the entire conditional block:
if (!brandingFeatureConfig.featureFlags.mapEmployees) {
this.onboardingSteps.splice(1, 1);
}
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check usage of mapEmployees feature flag
rg "mapEmployees"
Length of output: 2403
Script:
#!/bin/bash
# Check the onboarding steps definition and initialization
ast-grep --pattern 'onboardingSteps = [
$$$
]'
Length of output: 50
Script:
#!/bin/bash
# Search for onboarding steps initialization in the QBO onboarding model
rg -A 10 "onboardingSteps.*=" src/app/core/models/qbo/qbo-configuration/qbo-onboarding.model.ts
Length of output: 1041
Script:
#!/bin/bash
# Get the complete onboarding steps array initialization
rg -B 5 -A 20 "private onboardingSteps: OnboardingStepper\[\] = \[" src/app/core/models/qbo/qbo-configuration/qbo-onboarding.model.ts
Length of output: 1003
Line range hint 1-83
: Verify employee settings integration in export settings
Since the PR objective is to move employee settings to export settings, we should verify that the export settings component has been updated accordingly.
✅ Verification successful
Let me gather more specific information about the employee settings integration in the QBO export settings component.
Based on the evidence from the shell script outputs, I can now provide a final response:
Employee settings have been properly integrated into export settings
The QBO export settings component has successfully integrated employee settings as evidenced by:
- Employee settings form exists within the export settings template (
employeeSettingForm
) - Employee mapping configuration UI is present with proper fields:
- Employee representation in QuickBooks Online
- Auto-mapping options between Fyle and QuickBooks Online employees
- The employee settings section is properly integrated within the reimbursable expenses flow
- The component handles employee mapping type changes and their impact on export types
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check if employee settings have been properly integrated into export settings
# Look for export settings component
rg -A 10 "class.*ExportSettings"
# Check for employee-related configuration in export settings
rg -A 5 "employee.*settings"
Length of output: 37148
Script:
#!/bin/bash
# Check QBO export settings component for employee settings integration
ast-grep --pattern 'class QboExportSettingsComponent {
$$$
employeeSettings$_: $_
$$$
}'
# Look for employee settings related methods and properties in the export settings
rg -A 10 "employee.*settings.*=" src/app/integrations/qbo/qbo-shared/qbo-export-settings/qbo-export-settings.component.ts
# Check the template file for employee settings UI integration
cat src/app/integrations/qbo/qbo-shared/qbo-export-settings/qbo-export-settings.component.html
Length of output: 28984
54-58
: Verify step number adjustments after employee settings removal
The step numbers have been adjusted after removing the MAP_EMPLOYEES state. However, there's a potential inconsistency between the step numbers in onboardingStateStepMap
and the actual array indices in onboardingSteps
.
Let's verify the step numbers match the component routes:
✅ Verification successful
Let me try a different approach to verify the step numbers and routing consistency.
Let me check the routing configuration to verify the step numbers match the routes.
Based on the analysis of the codebase, I can now provide the final response:
Step numbers in onboardingStateStepMap are correctly aligned with component routes
The step numbers in onboardingStateStepMap
(2 for EXPORT_SETTINGS through 6 for CLONE_SETTINGS) are correctly aligned with the component routes and the onboarding flow. The getOnboardingSteps
method properly handles the step progression by:
- Setting the active state for the current step
- Marking previous steps as completed based on the step number
- Removing the employee mapping step when the feature flag is disabled
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check if the step numbers align with the routes in other components
# Look for route definitions and component declarations
# Search for route definitions
rg -A 3 "path.*qbo/onboarding"
# Search for component declarations
ast-grep --pattern 'class $name implements OnInit {
$$$
ngOnInit() {
$$$
}
}'
Length of output: 598
Script:
#!/bin/bash
# Search for QBO onboarding state usage and routing
rg -l "QBOOnboardingState"
# Check the content of relevant files
rg "QBOOnboardingState|onboardingStateStepMap|getOnboardingSteps" -A 3
# Look for stepper or navigation components
rg -l "stepper|onboarding.*component"
# Check routing module content
fd -e ts routing.module
Length of output: 66352
Script:
#!/bin/bash
# Check QBO routing configuration and component declarations
rg -A 5 "path.*qbo/onboarding" src/app/integrations/qbo
# Check QBO onboarding steps array
rg -A 10 "onboardingSteps.*=" src/app/core/models/qbo/qbo-configuration/qbo-onboarding.model.ts
Length of output: 1882
src/app/integrations/qbo/qbo-onboarding/qbo-onboarding-connector/qbo-onboarding-connector.component.ts (2)
107-107
: LGTM: Navigation path update is consistent
The navigation path change aligns with the PR objective of moving employee settings to export settings section.
170-170
: Verify the direct state transition to EXPORT_SETTINGS
The removal of conditional state transition logic needs verification to ensure it doesn't break existing workflows.
✅ Verification successful
Direct transition to EXPORT_SETTINGS state is consistent with other integrations
The verification shows that:
- The QBOOnboardingState enum defines a clear progression of states, with EXPORT_SETTINGS being a valid next state after CONNECTION
- Similar direct transitions to EXPORT_SETTINGS state after successful connection are implemented across multiple integration connectors (Xero, Sage300, NetSuite, Business Central)
- The removal of mapEmployees condition aligns with the standard pattern used in other integration flows
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for any dependencies on the removed mapEmployees feature flag
# and verify the state transition logic in other components
# Check for mapEmployees feature flag usage
rg -l "mapEmployees"
# Check for state transition references
rg -l "QBOOnboardingState.EXPORT_SETTINGS"
# Look for any employee settings related components that might be affected
fd -e ts -e html -x rg -l "employee.*settings"
Length of output: 1934
Script:
#!/bin/bash
# Let's check the state transition logic in the QBO onboarding component and related files
# Check the QBOOnboardingState enum definition and usage
ast-grep --pattern 'enum QBOOnboardingState {
$$$
}'
# Check the handlePostQBOConnection method implementation in the component
ast-grep --pattern 'handlePostQBOConnection() {
$$$
}'
# Look for any other state transitions to EXPORT_SETTINGS
rg "setOnboardingState.*EXPORT_SETTINGS" -A 2 -B 2
# Check the export settings component initialization
ast-grep --pattern 'export class QboExportSettingsComponent {
$$$
}'
Length of output: 5151
src/app/integrations/qbo/qbo-shared/qbo-export-settings/qbo-export-settings.component.ts (4)
122-133
: LGTM! Properties are well-defined.
The employee settings related properties are properly typed and initialized.
Line range hint 441-464
: LGTM! Form initialization is properly handled.
The form initialization in getSettingsAndSetupForm
is well-structured with proper error handling through the filter operator.
178-183
: 🛠️ Refactor suggestion
Add input validation to setLiveEntityExample method.
The method should validate the input array and handle edge cases.
Apply this improvement:
private setLiveEntityExample(destinationAttributes: DestinationAttribute[]): void {
+ if (!Array.isArray(destinationAttributes)) {
+ console.warn('Invalid destination attributes provided');
+ return;
+ }
this.liveEntityExample = {
[FyleField.EMPLOYEE]: destinationAttributes.find((attribute: DestinationAttribute) => attribute.attribute_type === FyleField.EMPLOYEE)?.value,
[FyleField.VENDOR]: destinationAttributes.find((attribute: DestinationAttribute) => attribute.attribute_type === FyleField.VENDOR)?.value
};
}
Likely invalid or redundant comment.
154-172
: 🛠️ Refactor suggestion
Error handling needs improvement.
The error handling in the save operation could be enhanced:
- The error callback doesn't handle specific error types
- The error message is generic and doesn't provide actionable information
Apply this improvement:
concat(
this.employeeSettingService.postEmployeeSettings(employeeSettingPayload),
this.exportSettingService.postExportSettings(exportSettingPayload)
).subscribe({
complete: () => {
this.isSaveInProgress = false;
this.toastService.displayToastMessage(ToastSeverity.SUCCESS, 'Export Settings saved successfully');
if (this.isOnboarding) {
this.workspaceService.setOnboardingState(QBOOnboardingState.IMPORT_SETTINGS);
this.router.navigate([`/integrations/qbo/onboarding/import_settings`]);
} else if (this.isAdvancedSettingAffected()) {
this.router.navigate(['/integrations/qbo/main/configuration/advanced_settings']);
}
},
- error: () => {
+ error: (error: HttpErrorResponse) => {
this.isSaveInProgress = false;
- this.toastService.displayToastMessage(ToastSeverity.ERROR, 'Error saving export settings, please try again later');
+ const errorMessage = error.error?.message || 'Error saving settings, please try again later';
+ this.toastService.displayToastMessage(ToastSeverity.ERROR, errorMessage);
+ console.error('Save settings error:', error);
}
});
Likely invalid or redundant comment.
src/app/integrations/qbo/qbo.fixture.ts (1)
342-342
: LGTM! Mock data is consistent.
The employee field mapping mock data is correctly updated to match the component changes.
src/app/integrations/qbo/qbo-onboarding/qbo-clone-settings/qbo-clone-settings.component.ts (1)
221-221
: Route updated to reflect new settings location
The navigation route change from 'employee_settings' to 'export_settings' aligns with the PR objective of moving employee settings to the export settings section.
Let's verify the route changes and related component usage:
✅ Verification successful
Route change is part of employee settings migration
The navigation route change from 'employee_settings' to 'export_settings' is consistent with the codebase changes. The verification shows:
- No remaining references to 'employee_settings' in routing modules
- No references to QboEmployeeSettingsComponent in routing configurations
- The employee settings model is still present but appears to be used within the export settings context, as evidenced by the model's usage in form groups and payload construction
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if employee_settings route/component is still referenced elsewhere
rg -l "employee_settings" --type ts
# Check if QboEmployeeSettingsComponent is still imported or used
ast-grep --pattern 'import { $$$QboEmployeeSettingsComponent$$$ } from $path'
Length of output: 187
Script:
#!/bin/bash
# Let's check the content of the model file to understand if it's still in use
cat src/app/core/models/qbo/qbo-configuration/qbo-employee-setting.model.ts
# Check for any references to QboEmployeeSettingsComponent in routing modules
rg "QboEmployeeSettingsComponent" --type ts
# Check for any remaining references to employee settings in the routes
rg "path.*employee" --type ts
Length of output: 2213
Script:
#!/bin/bash
# Let's check the routing module for QBO onboarding to see the current route configuration
rg -A 5 "export_settings" --type ts
# Check if there are any remaining references to employee settings in the component
rg "employee" src/app/integrations/qbo/qbo-onboarding/qbo-clone-settings/qbo-clone-settings.component.ts
Length of output: 65677
Script:
#!/bin/bash
# Let's check if there are any remaining references to employee settings in the QBO routing modules
rg -A 5 "employee_settings" --type ts
# Check for any QboEmployeeSettingsComponent references in the routing modules
rg -A 5 "QboEmployeeSettingsComponent" --type ts
Length of output: 1229
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.
discussed in slack
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
♻️ Duplicate comments (2)
src/app/integrations/qbo/qbo-shared/qbo-export-settings/qbo-export-settings.component.ts (2)
129-132
:⚠️ Potential issueEnsure “existingEmployeeFieldMapping” is assigned before usage.
There is no explicit assignment of "this.existingEmployeeFieldMapping" prior to creating the employeeSettingForm. This can lead to undefined values in the controls.Below is an example fix (assuming the existing mapping is the same as workspaceGeneralSettings.employee_field_mapping):
--- a/src/app/integrations/qbo/qbo-shared/qbo-export-settings/qbo-export-settings.component.ts +++ b/src/app/integrations/qbo/qbo-shared/qbo-export-settings/qbo-export-settings.component.ts @@ -493,0 +494,2 @@ + this.existingEmployeeFieldMapping = workspaceGeneralSettings.employee_field_mapping; +
508-511
:⚠️ Potential issueInitialize “existingEmployeeFieldMapping” before the form creation.
As noted previously, ensure that "existingEmployeeFieldMapping" is guaranteed to have a valid value before passing it into “createEmployeeSettingsForm.”
🧹 Nitpick comments (4)
src/app/integrations/qbo/qbo-shared/qbo-export-settings/qbo-export-settings.component.ts (3)
149-154
: Logic in “isEmployeeMappingDisabled” method is consistent, but consider clarifying the condition for readability.
Use a switch statement or a more descriptive code comment if you foresee adding more conditions.
156-173
: Optional: Use a switch-case for better readability.
The chain of if/else for setting “employeeMappingControl” could be more maintainable as a switch-case statement.Example refactor:
- if (exportType === QBOReimbursableExpensesObject.BILL) { - employeeMappingControl?.patchValue(EmployeeFieldMapping.VENDOR); - employeeMappingControl?.disable(); - } else if (exportType === QBOReimbursableExpensesObject.CHECK) { - ... - } + switch (exportType) { + case QBOReimbursableExpensesObject.BILL: + ... + break; + case QBOReimbursableExpensesObject.CHECK: + ... + break; + ... + }
488-490
: Check error handling for getDistinctQBODestinationAttributes.
Currently, the forkJoin call doesn’t account for potential errors from “getDistinctQBODestinationAttributes.” If that call fails, the rest of the forkJoin chain may fail. Consider adding error-handling logic to keep the rest of the setup robust.src/app/integrations/qbo/qbo-shared/qbo-export-settings/qbo-export-settings.component.html (1)
119-129
: Consider making autoMapEmployee field conditionalThe auto-map field might not be relevant for all employee mapping types. Consider adding a conditional rendering based on the selected
employeeMapping
value.+<div *ngIf="shouldShowAutoMapField()"> <app-configuration-select-field [form]="employeeSettingForm" ... [formControllerName]="'autoMapEmployee'"> </app-configuration-select-field> +</div>
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
src/app/integrations/qbo/qbo-shared/qbo-export-settings/qbo-export-settings.component.html
(2 hunks)src/app/integrations/qbo/qbo-shared/qbo-export-settings/qbo-export-settings.component.ts
(7 hunks)
🔇 Additional comments (10)
src/app/integrations/qbo/qbo-shared/qbo-export-settings/qbo-export-settings.component.ts (5)
Line range hint 2-22
: No issues with the updated import statements.
These additions look straightforward and appropriate for the newly introduced form controls, validation logic, models, and services.
122-124
: Initialization of new form references is valid.
Defining the employee-related form group and related properties is a good approach to keep them self-contained.
201-219
: Error handling is functional, but can be further improved.
The code references a generic error message. An earlier review discussed typed error handling for more clarity. Consider adding it here if needed.
225-230
: Validate inputs in “setLiveEntityExample.”
It would be safer to handle cases where destinationAttributes is null or undefined.
534-534
: LGTM on calling “setupExportTypeWatcher.”
This ensures watchers are initialized once the component sets up.
src/app/integrations/qbo/qbo-shared/qbo-export-settings/qbo-export-settings.component.html (5)
104-131
: Potential issue with nested forms
The employeeSettingForm
is nested within the exportSettingForm
, which could lead to unexpected behavior during form submission. Consider using form groups instead:
-<form [formGroup]="employeeSettingForm">
+<div [formGroupName]="'employeeSettings'">
<app-configuration-select-field
- [form]="employeeSettingForm"
+ [form]="exportSettingForm"
...
</app-configuration-select-field>
-</form>
+</div>
105-105
: LGTM: Proper conditional rendering
The employee settings section is correctly conditionally rendered based on brandingConfig.brandId === 'fyle'
as suggested in the past review comments.
35-35
: Verify the impact of getAllReimbursableExportTypeOptions()
The function name suggests it might be fetching all available options. Ensure it includes any new options required for the employee settings integration.
✅ Verification successful
No changes needed for getAllReimbursableExportTypeOptions()
The implementation correctly includes all possible reimbursable export types as defined in the QBOReimbursableExpensesObject enum (Check, Bill, Expense, and Journal Entry). The function is properly aligned with the employee settings integration as it already provides all available export type options from the enum.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for the implementation and usages of getAllReimbursableExportTypeOptions
ast-grep --pattern 'getAllReimbursableExportTypeOptions() {
$$$
}'
Length of output: 70
Script:
#!/bin/bash
# Let's try a broader search for the method name using ripgrep
rg -l "getAllReimbursableExportTypeOptions" --type ts --type html
# Then get the content of any matching files
echo "=== Content of matching files ==="
rg "getAllReimbursableExportTypeOptions" -A 5 --type ts --type html
Length of output: 2123
Script:
#!/bin/bash
# Let's see the complete implementation of getAllReimbursableExportTypeOptions
rg -A 15 "getAllReimbursableExportTypeOptions\(\): SelectFormOption" --type ts
# Also check the QBOReimbursableExpensesObject enum
rg "enum QBOReimbursableExpensesObject" -A 10 --type ts
Length of output: 2676
107-118
: Verify employee mapping options
The employee mapping select field is crucial for the integration. Ensure that:
- The options in
employeeMappingOptions
cover all possible employee representations in QuickBooks Online - The disabled state (
isEmployeeMappingDisabled()
) handles all edge cases
✅ Verification successful
Employee mapping configuration is properly implemented
The verification shows that:
-
Employee mapping options correctly cover all QuickBooks Online representations:
- Employee (EMPLOYEE)
- Vendor (VENDOR)
-
The disabled state logic is correctly implemented:
- Disabled when reimbursable export type is BILL, CHECK, or EXPENSE
- Enabled for JOURNAL ENTRY type exports
This implementation ensures proper employee representation mapping while maintaining consistency with QuickBooks Online's data model.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for employeeMappingOptions definition and usage
ast-grep --pattern 'employeeMappingOptions = $$$'
# Search for isEmployeeMappingDisabled implementation
ast-grep --pattern 'isEmployeeMappingDisabled() {
$$$
}'
Length of output: 112
Script:
#!/bin/bash
# Let's try a different pattern to find employeeMappingOptions
rg -A 5 "employeeMappingOptions" --type ts
# Search for isEmployeeMappingDisabled with a different pattern
rg -A 5 "isEmployeeMappingDisabled" --type ts
# Also search for any employee mapping related constants or types
rg "enum.*Employee.*Mapping" --type ts
Length of output: 4652
Script:
#!/bin/bash
# Let's check the employee mapping enum values
rg -A 10 "enum EmployeeFieldMapping" --type ts
# Let's also check the implementation of getEmployeeFieldMappingOptions
rg -A 10 "getEmployeeFieldMappingOptions" --type ts
# Check QBOReimbursableExpensesObject enum values to understand disabled states
rg -A 10 "enum QBOReimbursableExpensesObject" --type ts
Length of output: 6988
Line range hint 1-400
: Review the form submission handling
The form submission logic needs to handle both the export settings and employee settings data. Verify that the constructPayloadAndSave
method properly combines both forms' data.
✅ Verification successful
Based on the code review, I can now generate the final response since I have found clear evidence that the constructPayloadAndSave
method properly handles both forms' data:
Form submission correctly handles both export and employee settings data
The implementation in qbo-export-settings.component.ts shows that both forms are properly handled:
- Creates separate payloads for export settings (
exportSettingPayload
) and employee settings (employeeSettingPayload
) - Uses RxJS
concat
operator to sequentially save both settings via their respective services:concat( this.employeeSettingService.postEmployeeSettings(employeeSettingPayload), this.exportSettingService.postExportSettings(exportSettingPayload) )
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for the implementation of constructPayloadAndSave
ast-grep --pattern 'constructPayloadAndSave($$$) {
$$$
}'
Length of output: 61
Script:
#!/bin/bash
# Let's try searching for the method with ripgrep for better results
rg -g '*.ts' 'constructPayloadAndSave' -A 10
Length of output: 63437
Script:
#!/bin/bash
# Let's search for the QBO export settings component implementation to understand how both forms are handled
rg -g 'qbo-export-settings.component.ts' 'constructPayloadAndSave' -B 5 -A 15
Length of output: 6387
src/app/integrations/qbo/qbo-shared/qbo-export-settings/qbo-export-settings.component.ts
Outdated
Show resolved
Hide resolved
src/app/integrations/qbo/qbo-shared/qbo-export-settings/qbo-export-settings.component.ts
Outdated
Show resolved
Hide resolved
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
🧹 Nitpick comments (2)
src/app/integrations/qbo/qbo-shared/qbo-export-settings/qbo-export-settings.component.ts (2)
149-171
: Improve employee mapping logic robustnessThe employee mapping logic could be enhanced for better type safety and maintainability.
Consider applying these improvements:
isEmployeeMappingDisabled(): boolean { - const exportType = this.exportSettingForm.get('reimbursableExportType')?.value; + const exportType = this.exportSettingForm.get('reimbursableExportType')?.value || ''; - return exportType === QBOReimbursableExpensesObject.BILL || - exportType === QBOReimbursableExpensesObject.CHECK; + return [ + QBOReimbursableExpensesObject.BILL, + QBOReimbursableExpensesObject.CHECK + ].includes(exportType); } setupExportTypeWatcher(): void { this.exportSettingForm.get('reimbursableExportType')?.valueChanges.subscribe((exportType) => { const employeeMappingControl = this.employeeSettingForm.get('employeeMapping'); + if (!employeeMappingControl) { + return; + } if (exportType === QBOReimbursableExpensesObject.BILL) { employeeMappingControl?.patchValue(EmployeeFieldMapping.VENDOR); employeeMappingControl?.disable(); } else if (exportType === QBOReimbursableExpensesObject.CHECK) { employeeMappingControl?.patchValue(EmployeeFieldMapping.EMPLOYEE); employeeMappingControl?.disable(); - } else if (exportType === QBOReimbursableExpensesObject.EXPENSE) { - employeeMappingControl?.enable(); - } else if (exportType === QBOReimbursableExpensesObject.JOURNAL_ENTRY) { + } else if ([QBOReimbursableExpensesObject.EXPENSE, QBOReimbursableExpensesObject.JOURNAL_ENTRY].includes(exportType)) { employeeMappingControl?.enable(); } }); }
223-228
: Add null checks and type safety to setLiveEntityExampleThe method should handle null cases and provide better type safety.
Consider this improvement:
-private setLiveEntityExample(destinationAttributes: DestinationAttribute[]): void { +private setLiveEntityExample(destinationAttributes: DestinationAttribute[] | null): void { + if (!destinationAttributes?.length) { + this.liveEntityExample = { + [FyleField.EMPLOYEE]: undefined, + [FyleField.VENDOR]: undefined + }; + return; + } + this.liveEntityExample = { - [FyleField.EMPLOYEE]: destinationAttributes.find((attribute: DestinationAttribute) => attribute.attribute_type === FyleField.EMPLOYEE)?.value, - [FyleField.VENDOR]: destinationAttributes.find((attribute: DestinationAttribute) => attribute.attribute_type === FyleField.VENDOR)?.value + [FyleField.EMPLOYEE]: destinationAttributes.find((attribute) => + attribute.attribute_type === FyleField.EMPLOYEE + )?.value || undefined, + [FyleField.VENDOR]: destinationAttributes.find((attribute) => + attribute.attribute_type === FyleField.VENDOR + )?.value || undefined }; }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
src/app/integrations/qbo/qbo-shared/qbo-export-settings/qbo-export-settings.component.ts
(7 hunks)
🔇 Additional comments (4)
src/app/integrations/qbo/qbo-shared/qbo-export-settings/qbo-export-settings.component.ts (4)
19-22
: LGTM: Clean implementation of employee settings properties
The new imports and class properties are well-organized and follow Angular best practices.
Also applies to: 122-133
Line range hint 532-540
: LGTM: Well-organized watcher setup
The watcher setup is well-organized. The order of setup (export type, custom, date options) seems logical as it follows the dependency chain.
🧰 Tools
🪛 Biome (1.9.4)
[error] 530-530: Unnecessary use of boolean literals in conditional expression.
Simplify your code by directly assigning the result without using a ternary operator.
If your goal is negation, you may use the logical NOT (!) or double NOT (!!) operator for clearer and concise code.
Check for more details about NOT operator.
Unsafe fix: Remove the conditional expression with
(lint/complexity/noUselessTernary)
201-217
:
Enhance error handling in save operation
The current error handling is too generic and doesn't provide enough information for debugging or user feedback.
Apply this improvement:
concat(
this.employeeSettingService.postEmployeeSettings(employeeSettingPayload),
this.exportSettingService.postExportSettings(exportSettingPayload)
).subscribe({
complete: () => {
this.isSaveInProgress = false;
this.toastService.displayToastMessage(ToastSeverity.SUCCESS, 'Export Settings saved successfully');
if (this.isOnboarding) {
this.workspaceService.setOnboardingState(QBOOnboardingState.IMPORT_SETTINGS);
this.router.navigate([`/integrations/qbo/onboarding/import_settings`]);
} else if (this.isAdvancedSettingAffected()) {
this.router.navigate(['/integrations/qbo/main/configuration/advanced_settings']);
}
},
- error: () => {
+ error: (error: HttpErrorResponse) => {
this.isSaveInProgress = false;
+ let errorMessage = 'Error saving export settings, please try again later';
+ if (error.error?.message) {
+ errorMessage = `Error: ${error.error.message}`;
+ } else if (error.status === 0) {
+ errorMessage = 'Network error occurred, please check your connection';
+ }
- this.toastService.displayToastMessage(ToastSeverity.ERROR, 'Error saving export settings, please try again later');
+ this.toastService.displayToastMessage(ToastSeverity.ERROR, errorMessage);
+ console.error('Save settings failed:', error);
}
});
Likely invalid or redundant comment.
Line range hint 486-509
: Verify API call order and potential race conditions
The forkJoin usage for API calls could lead to race conditions if the calls have dependencies.
Run this script to verify the API call dependencies:
getAllReimbursableExportTypeOptions(): SelectFormOption[] { | ||
return [ | ||
{ | ||
label: 'Check', | ||
value: QBOReimbursableExpensesObject.CHECK | ||
}, | ||
{ | ||
label: 'Bill', | ||
value: QBOReimbursableExpensesObject.BILL | ||
}, | ||
{ | ||
label: 'Expense', | ||
value: QBOReimbursableExpensesObject.EXPENSE | ||
}, | ||
{ | ||
label: 'Journal Entry', | ||
value: QBOReimbursableExpensesObject.JOURNAL_ENTRY | ||
} | ||
]; | ||
} |
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.
🛠️ Refactor suggestion
Move export type options to model class
The export type options should be moved to the QBOExportSettingModel
class for better organization and maintainability.
Consider moving this logic to the model:
-getAllReimbursableExportTypeOptions(): SelectFormOption[] {
- return [
- {
- label: 'Check',
- value: QBOReimbursableExpensesObject.CHECK
- },
- {
- label: 'Bill',
- value: QBOReimbursableExpensesObject.BILL
- },
- {
- label: 'Expense',
- value: QBOReimbursableExpensesObject.EXPENSE
- },
- {
- label: 'Journal Entry',
- value: QBOReimbursableExpensesObject.JOURNAL_ENTRY
- }
- ];
-}
And in QBOExportSettingModel
:
static getAllReimbursableExportTypeOptions(): SelectFormOption[] {
return Object.values(QBOReimbursableExpensesObject).map(value => ({
label: value.replace(/_/g, ' ').toLowerCase()
.replace(/\b\w/g, l => l.toUpperCase()),
value
}));
}
|
Description
Clickup
Screen.Recording.2024-12-19.at.10.29.31.AM.mov
Summary by CodeRabbit
New Features
Bug Fixes
Documentation
Chores