feat(dot-analytics): update date filter options and enforce 7-day minimum range

[oidacra]

Proposed Changes

• Remove today and yesterday from the time period dropdown (TIME_PERIOD_OPTIONS)
• URL params time_range=today and time_range=yesterday now silently fall back to last7days; unrecognized values also fall back
• Custom date ranges now require a minimum span of 7 days (enforced via disabledDates computed signal)
• After selecting a start date, the 5 intermediate dates (start+1 to start+5) are visually disabled in the calendar
• Future date selection is blocked with [maxDate]="$today()"
• The calendar button bar now shows only a Clear button (Today button removed via #buttonbar ng-template override)

Acceptance Criteria

• AC1: today and yesterday removed from the time period dropdown
• AC2: Default period remains last7days
• AC3: URLs with today/yesterday as time_range silently fall back to last7days
• AC4: Custom date range must span a minimum of 7 days; calendar blocks invalid selections
• AC5: After selecting a start date, dates within 6 days after are visually disabled (grayed out)
• AC6: No future dates selectable ([maxDate] = today)
• AC7: Today button removed from the calendar's button bar

Test Coverage

23+ test cases covering all 7 ACs across portlet and data-access libraries.

portlets-dot-analytics: 249 tests passing (18 suites)
portlets-dot-analytics-data-access: 175 tests passing (5 suites)

Checklist

• Tests added/updated per test plan
• Translations required
• Security implications considered

Technical Notes

The [minDate] approach was discarded because PrimeNG's DatePicker in range mode does not update the ngModel after the first date click — only after both dates are selected. The fix uses (onSelect) to track the first click via $rangeStart signal, then computes the array of disabled dates from it.

Closes #34397

This PR fixes: #34397

[claude]

Claude finished @oidacra's task —— View job

---

Code Review Complete

I've analyzed the PR changes and found the implementation to be clean and well-designed. Here are the key aspects I reviewed:

What I Analyzed:

• Date range validation logic and minimum 7-day enforcement
• URL parameter handling and fallback behavior for deprecated options
• Calendar UI changes and disabled dates computation
• Edge cases in date calculations and PrimeNG integration

The Implementation is Solid:

1. Robust Date Validation (dot-analytics.utils.ts:15-31):

   • Correctly validates dates using date-fns parsing
   • Properly enforces minimum 7-day range with inclusive calculation
   • Handles edge cases like invalid dates and reversed ranges

2. Safe URL Parameter Handling (filters.utils.ts:31-58):

   • Clean fallback logic for deprecated today/yesterday values
   • Graceful handling of incomplete custom ranges
   • Comprehensive validation of all parameter combinations

3. Smart Calendar Disable Logic (dot-analytics-filters.component.ts:75-90):

   • Efficiently computes disabled dates using array generation
   • Handles both forward and backward date restrictions
   • Resets properly when no range is active

4. PrimeNG Integration Edge Case Handling (dot-analytics-filters.component.ts:127-143):

   • Addresses timing issues with PrimeNG's ControlValueAccessor
   • Correctly detects range resets when clicking before start date
   • Maintains consistent state between component signals and PrimeNG

5. Comprehensive Test Coverage: 23+ test cases covering all acceptance criteria across both libraries.

No Issues Found - The code handles edge cases well, has proper error boundaries, and maintains clean separation of concerns.

---

[semgrep-code-dotcms-test]

Legal Risk

The following dependencies were released under a license that
has been flagged by your organization for consideration.

Recommendation

While merging is not directly blocked, it's best to pause and consider what it means to use this license before continuing. If you are unsure, reach out to your security team or Semgrep admin to address this issue.

MPL-2.0

• lightningcss-android-arm64 1.31.1
• lightningcss-darwin-arm64 1.31.1
• lightningcss-darwin-x64 1.31.1
• lightningcss-freebsd-x64 1.31.1
• lightningcss-linux-arm-gnueabihf 1.31.1
• lightningcss-linux-arm64-gnu 1.31.1
• lightningcss-linux-arm64-musl 1.31.1
• lightningcss-linux-x64-gnu 1.31.1
• lightningcss-linux-x64-musl 1.31.1
• lightningcss-win32-arm64-msvc 1.31.1
• lightningcss-win32-x64-msvc 1.31.1
• lightningcss 1.31.1

[Copilot]

Pull request overview

This PR implements the requirements from issue #34397 to simplify and constrain the date filter options in the Analytics Dashboard portlet. It removes the today and yesterday filter options, enforces a 7-day minimum custom date range via UI constraints, and ensures stale URL parameters for removed options fall back to last7days.

Changes:

• Removes today and yesterday from the TIME_PERIOD_OPTIONS dropdown, with URL fallback handling in both the portlet utils and data-access layers
• Enforces a 7-day minimum custom date range via $disabledDates computed signal and isValidCustomDateRange validation; replaces the (onSelect) binding with a new onDateSelect handler that tracks first-click state and emits only valid complete ranges
• Replaces the inline router.navigate call with a new shared silentNavigate utility; fixes updateTimeRange to avoid triggering store state changes for bare 'custom' until full date range is selected

Reviewed changes

Copilot reviewed 11 out of 11 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
dot-analytics.utils.ts	Adds MIN_CUSTOM_DATE_RANGE_DAYS, updates isValidCustomDateRange to enforce 7-day minimum, adds getValidTimeRangeUrl with today/yesterday exclusion
dot-analytics.utils.spec.ts	Adds tests for new 7-day minimum validation and getValidTimeRangeUrl exclusion logic
dot-analytics.constants.ts	Removes today and yesterday entries from TIME_PERIOD_OPTIONS
dot-analytics-filters.component.ts	Adds $today, $rangeStart, $disabledDates signals; rewires date selection to onDateSelect; adds clearDateRange and onCalendarClosed; adds ButtonModule import
dot-analytics-filters.component.spec.ts	Comprehensive tests for all new signals and methods
dot-analytics-filters.component.html	Adds [maxDate], [disabledDates], (onClose), new #buttonbar ng-template with only a Clear button
dot-analytics-dashboard.component.spec.ts	Updates and adds tests for today/yesterday/invalid URL param fallback behavior
router.utils.ts	New shared silentNavigate utility to update URL without triggering router events
filters.utils.ts	Adds today/yesterday exclusion in paramsToTimeRange; adds validation against VALID_TIME_RANGE_VALUES
filters.utils.spec.ts	Adds tests for today/yesterday fallback in paramsToTimeRange

---

You can also share your feedback on Copilot code review. Take the survey.

[claude]

Claude finished @oidacra's task —— View job

---

Code Review Complete

Issues Found:

1. Logic Error in Date Validation (dot-analytics.utils.ts:25):

   • The isSameDay check is redundant and confusing. Line 25 allows same-day ranges to pass the order validation, only to be rejected at line 30 by the minimum span check. Since differenceInCalendarDays(same, same) = 0 and the minimum is 6, same-day ranges will always fail.

2. Dead Code (dot-analytics-filters.component.ts):

   • onChangeCustomDateRange method exists but is never called from the template. The component now uses onDateSelect exclusively. This creates maintenance debt and confusion.

3. Translation Issue (Addressed):

   • The analytics.filters.custom-date-range.clear translation key was properly added to Language.properties, so this is not an issue.

Minor Concerns:

4. Edge Case in Range Reset Logic (dot-analytics-filters.component.ts:130):
   • The isBefore(date, start) check assumes PrimeNG resets when clicking before start date, but this behavior could be version-dependent and fragile.

What's Good:

• Date validation logic correctly enforces 7-day minimum
• URL parameter fallback handling is comprehensive
• Calendar disabled dates computation works correctly
• Test coverage appears thorough

The implementation is mostly solid but has some cleanup opportunities around dead code and redundant logic.

[claude]

Claude finished @oidacra's task —— View job

---

Review Complete

Issues Found:

1. Logic Inconsistency in Date Validation (dot-analytics.utils.ts:25)

• The !isBefore(fromDateObj, toDateObj) check rejects same-day ranges, but line 30 also rejects them with the minimum span check
• This creates redundant validation where same-day ranges fail twice for different reasons
• The logic is correct but unnecessarily complex

2. Fragile PrimeNG Integration (dot-analytics-filters.component.ts:130)

• The isBefore(date, start) reset detection relies on undocumented PrimeNG behavior
• Could break if PrimeNG changes its internal range-picking logic in future versions

3. Unbounded Disabled Dates (dot-analytics-filters.component.ts:84-88)

• addDays(start, -i) can generate dates far in the past without bounds checking
• May create unnecessary disabled date arrays when start date is near application epoch

4. State Synchronization Workaround (dot-analytics-filters.component.ts:121)

• Acknowledges timing issues with PrimeNG's ControlValueAccessor
• Uses workaround that's clever but potentially brittle

The implementation works correctly but has some areas where the logic could be cleaner and more resilient to external library changes.

---

View job

[claude]

Claude finished @oidacra's task —— View job

---

PR Review Complete

Issues Found:

1. Dead Code in Component (dot-analytics-filters.component.ts:162-176)

• The onChangeCustomDateRange method exists but is never called from the template
• Template now exclusively uses onDateSelect for all calendar interactions
• This creates maintenance confusion and should be removed

2. Test Organization Issue (dot-analytics-filters.component.spec.ts:246-263)

• Two tests calling onChangeCustomDateRange are incorrectly placed inside the describe('onDateSelect (range picking)') block
• These tests are for a different method and create misleading test structure
• Should either be moved to separate block or updated to test onDateSelect behavior

3. Potential Edge Case in Reset Logic (dot-analytics-filters.component.ts:130)

• The isBefore(date, start) condition assumes PrimeNG resets selection when clicking before start date
• This behavior is implementation-specific and could break with PrimeNG version updates
• While it works currently, it's fragile and undocumented

What's Clean:

• Date validation logic correctly enforces 7-day minimum span
• URL parameter fallback handling is comprehensive and well-tested
• Calendar disabled dates computation works correctly
• Translation key was properly added to Language.properties
• Test coverage is thorough (23+ test cases)
• Security concerns are minimal - input validation is appropriate

The implementation is functionally correct but has cleanup opportunities around dead code and test organization.

---