Skip to content

WEB-357 Editing a holiday fails due to failure to parse from date format#2753

Merged
alberto-art3ch merged 1 commit intoopenMF:devfrom
JaySoni1:WEB-357-editing-a-holiday-fails-due-to-failure-to-parse-from-date-format
Nov 4, 2025
Merged

WEB-357 Editing a holiday fails due to failure to parse from date format#2753
alberto-art3ch merged 1 commit intoopenMF:devfrom
JaySoni1:WEB-357-editing-a-holiday-fails-due-to-failure-to-parse-from-date-format

Conversation

@JaySoni1
Copy link
Contributor

@JaySoni1 JaySoni1 commented Nov 4, 2025

Changes Made :-

-Fixed date formatting for [fromDate], [toDate],and [repaymentsRescheduledTo] fields in the Edit Holiday form.

WEB-357

Summary by CodeRabbit

  • Bug Fixes
    • Improved date field processing in the holiday edit interface to ensure consistent and reliable formatting when updating holiday schedules and rescheduled repayment dates. Date values are now directly validated and formatted based on their type, eliminating previous dependencies on cached form values.

@coderabbitai
Copy link

coderabbitai bot commented Nov 4, 2025

Walkthrough

The change refactors date formatting logic in the holiday edit component's submit handler. Previously conditional formatting based on scheduling type and previous form values is replaced with direct type-checking of date fields, simplifying the code path and removing dependencies on cached previous values.

Changes

Cohort / File(s) Summary
Date Formatting Refactor
src/app/organization/holidays/edit-holiday/edit-holiday.component.ts
Simplified date field formatting in submit logic: fromDate and toDate now formatted directly based on type checks (if Date) rather than relying on conditional scheduling type checks and previous form values. repaymentsRescheduledTo formatting preserved but scoped after other date fields.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

  • Verify that the direct type-checking approach (if Date) handles all input scenarios correctly across different scheduling types
  • Ensure removal of prevFromDate/prevToDate dependencies doesn't break any edge cases or form state management
  • Confirm the new date formatting order maintains correct data transformation for the API payload

Suggested reviewers

  • gkbishnoi07

Pre-merge checks and finishing touches

✅ Passed checks (2 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title clearly describes the main fix: addressing date format parsing failures in the holiday editing feature, which aligns with the code changes to date formatting in edit-holiday.component.ts.
✨ Finishing touches
  • 📝 Generate docstrings
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

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

Copy link

@coderabbitai coderabbitai bot left a 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 (1)
src/app/organization/holidays/edit-holiday/edit-holiday.component.ts (1)

133-148: Consider adding explicit typing for better type safety.

While the current implementation works correctly, holidayFormData has an implicit any type from UntypedFormGroup.value. Consider defining an explicit interface or type for the holiday form data to improve type safety and IDE support.

As per coding guidelines

interface HolidayFormData {
  name: string;
  description?: string;
  fromDate?: Date | string;
  toDate?: Date | string;
  reschedulingType?: number;
  repaymentsRescheduledTo?: Date | string;
}

submit() {
  const holidayFormData: HolidayFormData = this.holidayForm.value;
  // ... rest of the method
}
📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 28beb14 and 7ed03d6.

📒 Files selected for processing (1)
  • src/app/organization/holidays/edit-holiday/edit-holiday.component.ts (1 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
src/app/**

⚙️ CodeRabbit configuration file

src/app/**: For Angular code: verify component separation, trackBy on *ngFor,
strict type safety, and clean observable patterns.

Files:

  • src/app/organization/holidays/edit-holiday/edit-holiday.component.ts
🧬 Code graph analysis (1)
src/app/organization/holidays/edit-holiday/edit-holiday.component.ts (1)
src/app/settings/settings.service.ts (1)
  • dateFormat (111-113)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
  • GitHub Check: Run Lint, Build and Deploy
🔇 Additional comments (1)
src/app/organization/holidays/edit-holiday/edit-holiday.component.ts (1)

137-148: LGTM! The refactored date formatting logic is cleaner and more maintainable.

The direct type-checking approach using instanceof Date is more straightforward than the previous conditional logic. Each date field is now formatted independently based on its runtime type, which eliminates dependencies on cached previous values and makes the code easier to reason about.

Copy link
Collaborator

@alberto-art3ch alberto-art3ch left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@alberto-art3ch alberto-art3ch merged commit 1fbd90a into openMF:dev Nov 4, 2025
3 checks passed
@JaySoni1
Copy link
Contributor Author

JaySoni1 commented Nov 4, 2025

@alberto-art3ch Thank you for the review

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants