feat(availability): add preset hours dropdown to new schedule dialog#29661
feat(availability): add preset hours dropdown to new schedule dialog#29661veronikal24 wants to merge 1 commit into
Conversation
Adds a "Starting hours" select field to the Add New Schedule dialog with three options: Custom (no preset), Morning (6 AM–12 PM Mon–Fri), and Evening (5 PM–10 PM Mon–Fri). Selected preset is passed as the initial schedule time ranges when creating the schedule. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
Welcome to Cal.diy, @veronikal24! Thanks for opening this pull request. A few things to keep in mind:
A maintainer will review your PR soon. Thanks for contributing! |
📝 WalkthroughWalkthrough
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (2)
apps/web/modules/schedules/components/NewScheduleButton.tsx (2)
11-12: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winAvoid the
@calcom/ui/components/formbarrel here.This change reintroduces a barrel import for the touched form components. Please switch these to direct source imports so the file stays aligned with the UI package import contract. As per coding guidelines, "Import directly from source files, not barrel files" and "Never use barrel imports from index.ts files".
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@apps/web/modules/schedules/components/NewScheduleButton.tsx` around lines 11 - 12, The touched form imports in NewScheduleButton should not use the `@calcom/ui/components/form` barrel. Update the Form, SelectField, and InputField imports to come from their direct source modules instead of the barrel so the file follows the UI package import contract and avoids index-based reexports.Source: Coding guidelines
17-25: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winRewrite or drop these comments.
These additions describe the implementation rather than the reason for it. If the helper needs documentation, capture why UTC anchoring/weekday ordering matters; otherwise remove the comments. As per coding guidelines, "Only add code comments that explain why, not what" and "Never add comments that simply restate what the code does".
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@apps/web/modules/schedules/components/NewScheduleButton.tsx` around lines 17 - 25, The comments in buildWeekdayRanges are implementation notes rather than rationale, so either remove them or rewrite them to explain why UTC anchoring and weekday ordering are necessary. Update the documentation near the buildWeekdayRanges helper in NewScheduleButton so it captures the intent behind the UTC Date construction and the Mon-Fri mapping, without restating what the code does.Source: Coding guidelines
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@apps/web/modules/schedules/components/NewScheduleButton.tsx`:
- Around line 33-35: The `custom` option in `NewScheduleButton` still ends up
using `DEFAULT_SCHEDULE` because the create flow treats a missing `schedule` as
fallback, so make `custom` represent an explicit blank schedule instead. Update
the `scheduleOptions` entry for `custom` and the related create handler logic so
the `createSchedule` path can distinguish “no preset” from “use default,” using
the unique `buildWeekdayRanges`, `DEFAULT_SCHEDULE`, and `input.schedule`
handling in `NewScheduleButton` as the place to fix it.
---
Nitpick comments:
In `@apps/web/modules/schedules/components/NewScheduleButton.tsx`:
- Around line 11-12: The touched form imports in NewScheduleButton should not
use the `@calcom/ui/components/form` barrel. Update the Form, SelectField, and
InputField imports to come from their direct source modules instead of the
barrel so the file follows the UI package import contract and avoids index-based
reexports.
- Around line 17-25: The comments in buildWeekdayRanges are implementation notes
rather than rationale, so either remove them or rewrite them to explain why UTC
anchoring and weekday ordering are necessary. Update the documentation near the
buildWeekdayRanges helper in NewScheduleButton so it captures the intent behind
the UTC Date construction and the Mon-Fri mapping, without restating what the
code does.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 41d2384b-65a5-4825-be46-fd1149da15c4
📒 Files selected for processing (2)
apps/web/modules/schedules/components/NewScheduleButton.tsxpackages/i18n/locales/en/common.json
| custom: { label: "custom_hours", schedule: undefined }, | ||
| morning: { label: "morning_hours", schedule: buildWeekdayRanges(6, 12) }, | ||
| evening: { label: "evening_hours", schedule: buildWeekdayRanges(17, 22) }, |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
custom still creates the default schedule.
custom maps to undefined, but the create handler falls back to DEFAULT_SCHEDULE whenever input.schedule is missing. So this option does not behave like "no preset"—it silently creates the standard default hours instead. Send an explicit empty 7-day schedule here if the intent is a blank starting point.
Proposed fix
+const EMPTY_SCHEDULE = Array.from({ length: 7 }, () => [] as { start: Date; end: Date }[]);
+
const SCHEDULE_PRESETS: Record<
SchedulePreset,
{ label: string; schedule: { start: Date; end: Date }[][] | undefined }
> = {
- custom: { label: "custom_hours", schedule: undefined },
+ custom: { label: "custom_hours", schedule: EMPTY_SCHEDULE },
morning: { label: "morning_hours", schedule: buildWeekdayRanges(6, 12) },
evening: { label: "evening_hours", schedule: buildWeekdayRanges(17, 22) },
};📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| custom: { label: "custom_hours", schedule: undefined }, | |
| morning: { label: "morning_hours", schedule: buildWeekdayRanges(6, 12) }, | |
| evening: { label: "evening_hours", schedule: buildWeekdayRanges(17, 22) }, | |
| const EMPTY_SCHEDULE = Array.from({ length: 7 }, () => [] as { start: Date; end: Date }[]); | |
| const SCHEDULE_PRESETS: Record< | |
| SchedulePreset, | |
| { label: string; schedule: { start: Date; end: Date }[][] | undefined } | |
| > = { | |
| custom: { label: "custom_hours", schedule: EMPTY_SCHEDULE }, | |
| morning: { label: "morning_hours", schedule: buildWeekdayRanges(6, 12) }, | |
| evening: { label: "evening_hours", schedule: buildWeekdayRanges(17, 22) }, | |
| }; |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@apps/web/modules/schedules/components/NewScheduleButton.tsx` around lines 33
- 35, The `custom` option in `NewScheduleButton` still ends up using
`DEFAULT_SCHEDULE` because the create flow treats a missing `schedule` as
fallback, so make `custom` represent an explicit blank schedule instead. Update
the `scheduleOptions` entry for `custom` and the related create handler logic so
the `createSchedule` path can distinguish “no preset” from “use default,” using
the unique `buildWeekdayRanges`, `DEFAULT_SCHEDULE`, and `input.schedule`
handling in `NewScheduleButton` as the place to fix it.
bandhan-majumder
left a comment
bandhan-majumder
left a comment
There was a problem hiding this comment.
for feature requests, please create an issue first!
2 participants
Adds a "Starting hours" select field to the Add New Schedule dialog with three options: Custom (no preset), Morning (6 AM–12 PM Mon–Fri), and Evening (5 PM–10 PM Mon–Fri). Selected preset is passed as the initial schedule time ranges when creating the schedule.
What does this PR do?
Visual Demo (For contributors especially)
A visual demonstration is strongly recommended, for both the original and new change (video / image - any one).
Video Demo (if applicable):
Image Demo (if applicable):
Mandatory Tasks (DO NOT REMOVE)
How should this be tested?
Checklist