Add advanced datetime and range selection documentation#1495
Add advanced datetime and range selection documentation#1495
Conversation
Document new datetime_config features including timezone support, manual time entry, and date/datetime range selection for interactive dialogs. Co-Authored-By: Claude Sonnet 4.5 (1M context) <noreply@anthropic.com>
|
Newest code from mattermost has been published to preview environment for Git SHA 0c52d3c |
|
Newest code from mattermost has been published to preview environment for Git SHA fa0a798 |
|
Newest code from mattermost has been published to preview environment for Git SHA c886043 |
📝 WalkthroughWalkthroughAdds comprehensive documentation for Advanced DateTime Configuration feature (v11.6) to the interactive dialogs plugin guide. Covers datetime_config object structure, timezone support, manual time entry, date range configurations, and multiple usage examples with backward compatibility notes. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes 🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ 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: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@site/content/integrate/plugins/interactive-dialogs/_index.md`:
- Around line 624-645: The example uses DST-sensitive labels (the prose "GMT"
and "UTC-7" and the JSON "location_timezone": "Europe/London"), which can be
incorrect part of the year; update the prose and example so it uses the IANA
zone name (e.g., reference "Europe/London" and "America/Denver") instead of
fixed GMT/UTC offsets or explicitly anchor the example to a specific date (e.g.,
include the date used for the conversion like "2024-03-15") and adjust the
displayed/returned time accordingly; change the help_text/indicator from "Times
shown in GMT" to something like "Times shown in Europe/London (may observe DST)"
or otherwise clarify DST behavior so the fields "display_name", "help_text",
"datetime_config.location_timezone" and the prose around the 🌍 indicator are
consistent and accurate year-round.
- Around line 836-849: Update the "Form Submission Format" section to document
the partial payload shape: state that an optional range with only a start date
submits as a single-element array (e.g. ["2024-03-15"] for date ranges and
["2024-03-15T09:00:00-05:00"] for datetime ranges), and clarify this contrasts
with empty optional ranges (null or []) and full ranges (two-element arrays).
Reference the existing headings "Required Range Fields", "Date Constraints", and
the allow_single_day_range examples so readers can see how the partial case
relates to optional fields and datetime handling.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 3c377da2-d7d1-4de8-af24-e65678cdf5b6
📒 Files selected for processing (1)
site/content/integrate/plugins/interactive-dialogs/_index.md
| | Property | Type | Description | | ||
| |----------|------|-------------| | ||
| | `time_interval` | Integer | Time selection interval in minutes (1-1440, must be divisor of 1440). Default: 60. | | ||
| | `location_timezone` | String | IANA timezone for displaying times (e.g., "America/New_York", "Europe/London", "Asia/Tokyo"). When set, times are shown in this timezone with an indicator. Values are still stored in UTC. | | ||
| | `allow_manual_time_entry` | Boolean | When `true`, shows a text input for typing times instead of dropdown. Supports formats: `9am`, `3:45pm`, `14:30`, `12a`. Default: `false`. | |
There was a problem hiding this comment.
Clarify whether datetime submissions stay in UTC or preserve an offset.
This section says location_timezone values are stored in UTC and the example submits ...Z, but the existing submission docs later in the page say datetime values are sent as RFC3339 strings with an offset. Those two contracts are not interchangeable, and integrators will parse them differently. Please make the property description and examples match the actual submission format end-to-end.
Also applies to: 639-644, 684-688
| Display event times in a specific timezone (useful for global teams): | ||
|
|
||
| ```json | ||
| { | ||
| "display_name": "London Office Hours", | ||
| "name": "london_time", | ||
| "type": "datetime", | ||
| "help_text": "Times shown in GMT (with 🌍 indicator)", | ||
| "datetime_config": { | ||
| "location_timezone": "Europe/London", | ||
| "time_interval": 60 | ||
| } | ||
| } | ||
| ``` | ||
|
|
||
| **Behavior:** | ||
| - User in Denver (UTC-7) sees times in London (GMT) | ||
| - Dropdown shows: 00:00, 01:00, 02:00 (London time) | ||
| - User selects 14:00 (2 PM London) | ||
| - Value submitted: `2024-03-15T14:00:00Z` (UTC) | ||
| - 🌍 indicator shows "Times in GMT" | ||
|
|
There was a problem hiding this comment.
Avoid DST-sensitive timezone labels in the London example.
Europe/London is not always GMT, and Denver is not always UTC-7. Hard-coding those labels makes the example wrong for part of the year. Using the IANA zone names in the prose, or anchoring the example to a specific date when GMT/UTC-7 applies, would keep this accurate year-round.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@site/content/integrate/plugins/interactive-dialogs/_index.md` around lines
624 - 645, The example uses DST-sensitive labels (the prose "GMT" and "UTC-7"
and the JSON "location_timezone": "Europe/London"), which can be incorrect part
of the year; update the prose and example so it uses the IANA zone name (e.g.,
reference "Europe/London" and "America/Denver") instead of fixed GMT/UTC offsets
or explicitly anchor the example to a specific date (e.g., include the date used
for the conversion like "2024-03-15") and adjust the displayed/returned time
accordingly; change the help_text/indicator from "Times shown in GMT" to
something like "Times shown in Europe/London (may observe DST)" or otherwise
clarify DST behavior so the fields "display_name", "help_text",
"datetime_config.location_timezone" and the prose around the 🌍 indicator are
consistent and accurate year-round.
| **Required Range Fields:** | ||
| - Both start and end dates must be selected for required fields | ||
| - Submitting with only a start date will show a validation error with code `"range_incomplete"` | ||
| - Optional range fields with only a start date are considered valid | ||
|
|
||
| **Date Constraints:** | ||
| - For datetime ranges, the end date picker automatically disables dates before the start date | ||
| - If `allow_single_day_range` is `false`, the start date itself is also disabled in the end picker | ||
| - If `allow_single_day_range` is `true`, users can select the same date for both start and end | ||
|
|
||
| **Form Submission Format:** | ||
| - Date ranges submit as string arrays: `["2024-03-15", "2024-03-20"]` | ||
| - DateTime ranges submit as string arrays with timezone: `["2024-03-15T09:00:00-05:00", "2024-03-15T17:00:00-05:00"]` | ||
| - Empty optional range fields submit as `null` or empty array |
There was a problem hiding this comment.
Document the payload for a partially filled optional range.
These lines say an optional range with only a start date is valid, but the submission section only shows full two-value arrays and empty/null cases. Please spell out the exact payload shape for the partial case as well, otherwise consumers cannot implement reliable parsing or validation.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@site/content/integrate/plugins/interactive-dialogs/_index.md` around lines
836 - 849, Update the "Form Submission Format" section to document the partial
payload shape: state that an optional range with only a start date submits as a
single-element array (e.g. ["2024-03-15"] for date ranges and
["2024-03-15T09:00:00-05:00"] for datetime ranges), and clarify this contrasts
with empty optional ranges (null or []) and full ranges (two-element arrays).
Reference the existing headings "Required Range Fields", "Date Constraints", and
the allow_single_day_range examples so readers can see how the partial case
relates to optional fields and datetime handling.
1 participant
Summary
Documents new interactive dialog datetime features introduced in v11.6, including advanced configuration options, timezone support, and range selection capabilities.
Summary
Ticket Link
Fixes https://mattermost.atlassian.net/browse/MM-65082
Summary by CodeRabbit
Release Notes