Allen HouchinsandNoah Talerman
3906398928
This pull request updates the logic for scheduling calendar events to always select the next business day (skipping weekends) instead of scheduling on the next Tuesday. The test suite for this functionality has also been rewritten to reflect the new behavior and to improve clarity. **Business logic update:** * Changed `getPreferredCalendarEventDate` in `calendar_cron.go` to return the next business day after the provided date, skipping weekends, instead of always selecting the next Tuesday. **Test updates:** * Refactored the test cases in `calendar_cron_test.go` to use specific `today` dates and expected results, ensuring coverage for weekday transitions, weekend skipping, and month/year rollovers. The tests now directly check the next business day logic rather than iterating over ranges of days. **Related issue:** Resolves # # Checklist for submitter If some of the following don't apply, delete the relevant line. - [x] Changes file added for user-visible changes in `changes/`, `orbit/changes/` or `ee/fleetd-chrome/changes`. See [Changes files](https://github.com/fleetdm/fleet/blob/main/docs/Contributing/guides/committing-changes.md#changes-files) for more information. - [ ] Input data is properly validated, `SELECT *` is avoided, SQL injection is prevented (using placeholders for values in statements), JS inline code is prevented especially for url redirects, and untrusted data interpolated into shell scripts/commands is validated against shell metacharacters. - [ ] Timeouts are implemented and retries are limited to avoid infinite loops - [ ] If paths of existing endpoints are modified without backwards compatibility, checked the frontend/CLI for any necessary changes ## Testing - [x] Added/updated automated tests - [ ] Where appropriate, [automated tests simulate multiple hosts and test for host isolation](https://github.com/fleetdm/fleet/blob/main/docs/Contributing/reference/patterns-backend.md#unit-testing) (updates to one hosts's records do not affect another) - [ ] QA'd all new/changed functionality manually For unreleased bug fixes in a release candidate, one of: - [ ] Confirmed that the fix is not expected to adversely impact load test results - [ ] Alerted the release DRI if additional load testing is needed ## Database migrations - [ ] Checked schema for all modified table for columns that will auto-update timestamps during migration. - [ ] Confirmed that updating the timestamps is acceptable, and will not cause unwanted side effects. - [ ] Ensured the correct collation is explicitly set for character columns (`COLLATE utf8mb4_unicode_ci`). ## New Fleet configuration settings - [ ] Setting(s) is/are explicitly excluded from GitOps If you didn't check the box above, follow this checklist for GitOps-enabled settings: - [ ] Verified that the setting is exported via `fleetctl generate-gitops` - [ ] Verified the setting is documented in a separate PR to [the GitOps documentation](https://github.com/fleetdm/fleet/blob/main/docs/Configuration/yaml-files.md#L485) - [ ] Verified that the setting is cleared on the server if it is not supplied in a YAML file (or that it is documented as being optional) - [ ] Verified that any relevant UI is disabled when GitOps mode is enabled ## fleetd/orbit/Fleet Desktop - [ ] Verified compatibility with the latest released version of Fleet (see [Must rule](https://github.com/fleetdm/fleet/blob/main/docs/Contributing/workflows/fleetd-development-and-release-strategy.md)) - [ ] If the change applies to only one platform, confirmed that `runtime.GOOS` is used as needed to isolate changes - [ ] Verified that fleetd runs on macOS, Linux and Windows - [ ] Verified auto-update works from the released version of component to the new version (see [tools/tuf/test](../tools/tuf/test/README.md)) <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Bug Fixes** * Calendar events now schedule on the next business day (skipping weekends) after a policy failure instead of a fixed weekly day. * **Tests** * Updated unit tests to validate the new next-business-day behavior with explicit expected dates. * **Documentation** * Updated scheduling description to reflect next-business-day remediation timing. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Noah Talerman <47070608+noahtalerman@users.noreply.github.com>
3.1 KiB
3.1 KiB
Using maintenance windows (Fleet in your calendar)
Fleet helps end users fix issues on their own by scheduling a maintenance window directly on their calendar—no IT ticket required.
When a host fails a policy (e.g. MDM enrollment profile expired, disk encryption disabled, outdated software), Fleet can notify the user via a Google Calendar event. The event includes:
- What’s wrong (based on policy description)
- What to do (from the policy resolution field)
- A scheduled time (next available slot on the next business day, 9–5 local time)
The user can reschedule if needed—Fleet will respect the new time and run the remediation then.
You can customize these flows with a webhook (e.g. Tines) to run scripts, use the Fleet API, or call MDM commands.
Setup
- Connect a Google Workspace service account to Fleet under Settings > Integrations > Calendars.
- Create a webhook to handle the remediation (see Fleet + Tines guide).
- In the Policies tab, click Manage automations > Calendar events, enable the feature, and paste your webhook URL.
End user experience
- If a user owns multiple failing hosts, only one host is scheduled at a time. Once it's fixed, Fleet schedules the next.
- If a host has multiple users, Fleet chooses one user to receive the event based on email priority:
- First priority: IdP Username email address (from MDM IdP accounts or manually set IdP email)
- Second priority: Google Chrome profile email address
- If multiple Google Chrome profile emails exist, Fleet selects the first one alphabetically
- Third priority: other email sources
- Users can reschedule the event on their calendar—Fleet will run remediation at the new time.
- If a user moves the event to before the current time, Fleet shifts it to the next business day.
- If a user deletes the event, Fleet automatically reschedules it for the next business day.
- Fleet monitors calendar changes in real time (reschedules within ~30 seconds), but only for events in the upcoming week. Events further out are updated within 30 minutes.
What happens when a policy fails?
- A calendar event is scheduled for the user who owns the host.
- Fleet waits for the scheduled time, then calls the webhook with host + failure details.
For more info: