Skip to content

fix(event-types): persist booking frequency limits on team event types + style limit-reached page#114

Merged
olivierlambert merged 4 commits into
mainfrom
fix/booking-frequency-limits
May 22, 2026
Merged

fix(event-types): persist booking frequency limits on team event types + style limit-reached page#114
olivierlambert merged 4 commits into
mainfrom
fix/booking-frequency-limits

Conversation

@olivierlambert

@olivierlambert olivierlambert commented May 22, 2026

Copy link
Copy Markdown
Owner

Summary

Two related bugs in the booking frequency limits feature:

  • Team event types silently dropped the toggle. edit_group_event_type_form did not load booking_frequency_limits from the DB (so the toggle always appeared off, even when rows existed), and create_group_event_type / update_group_event_type never wrote to it. Toggling on a team event type was a no-op; toggling off — if you somehow had a row — was also a no-op. Fix mirrors the load / save / delete-and-save pattern already used in the personal flow (`update_event_type` at `src/web/mod.rs:4770`).
  • Limit-reached page was unstyled raw HTML. The four booking handlers returned `Html("This event type has reached its booking limit for this period.")` with no template, producing a bare-paragraph error page. They now render through the existing `booking_action_error.html` template. Helper renamed `render_claim_error` → `render_booking_action_error` since the template isn't claim-specific.

Test plan

  • `cargo check`, `cargo fmt --check`, `cargo clippy -- -D warnings` clean
  • `cargo test` — 641 passing
  • On a personal event type: enable a frequency limit, save, reopen the form — toggle is still on; toggle off, save, reopen — toggle is off
  • On a team event type: same round-trip works
  • Trigger the limit on the public booking page — error page is styled (uses the standard error card), not a raw line of text

🤖 Generated with Claude Code

olivierlambert and others added 4 commits May 22, 2026 09:35
…s and style the limit-reached page

Team event types silently dropped the "Limit booking frequency" toggle:
the team form load did not read booking_frequency_limits, and the
create/update handlers never wrote to it. Wire the same load/save the
personal flow uses.

Also replace the four raw Html() "limit reached" responses in the booking
handlers with the existing booking_action_error.html template (helper
renamed render_claim_error -> render_booking_action_error since the
template isn't claim-specific).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…der coverage

under_tarpaulin() was keying off CARGO_TARPAULIN_VERSION, but
cargo-tarpaulin doesn't set that env var (verified locally with v0.35.4),
so the skip never fired and internal_error_logs_capture_underlying_detail
panicked under the Coverage CI job. cargo-tarpaulin compiles with
--cfg=tarpaulin, so cfg!(tarpaulin) is the reliable detection. Add the
matching check-cfg lint config so the cfg name passes -D unexpected_cfgs.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
"Event type has reached its booking limit for the current period" leaks
host-side jargon onto the guest. Use a phrase the guest will actually
parse: the meeting is full, try a different date.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
"Fully booked" implies sold-out capacity; here the host just configured
a per-period cap. Reword so the guest understands it's a host setting,
not exhausted availability.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@olivierlambert olivierlambert merged commit 3b652dc into main May 22, 2026
4 checks passed
@olivierlambert olivierlambert deleted the fix/booking-frequency-limits branch May 22, 2026 08:34
olivierlambert added a commit that referenced this pull request May 22, 2026
Minor release with two themes: closing the 1.10.2 sync-robustness
hotfix loop (the three follow-ups filed against #105 / #106 / #107)
and turning the booking-frequency-limits surface from a half-wired
feature into a real one — first by hiding capped slots in the picker
(#116), then by adding per-team-member caps (#118).

Highlights:
- Sync robustness: HEAD-check resource before cancelling (#108),
  scope cancel_orphaned by source/account (#111), propstat-aware
  parser ignores property-level 404s (#109).
- Booking frequency limits: team event type save/load fixed and
  limit-reached page styled (#114); slot picker hides capped periods
  (#116); per-member opt-in flag with full picker/submit/round-robin
  enforcement (#118).
- Migration 051 adds booking_frequency_limits.per_member.

650 tests total, up from 634 in 1.10.2. See CHANGELOG.md for details.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
huntervcx pushed a commit to DYB-Corp/calrs that referenced this pull request Jun 25, 2026
…s + style limit-reached page (olivierlambert#114)

* fix(event-types): persist booking frequency limits on team event types and style the limit-reached page

Team event types silently dropped the "Limit booking frequency" toggle:
the team form load did not read booking_frequency_limits, and the
create/update handlers never wrote to it. Wire the same load/save the
personal flow uses.

Also replace the four raw Html() "limit reached" responses in the booking
handlers with the existing booking_action_error.html template (helper
renamed render_claim_error -> render_booking_action_error since the
template isn't claim-specific).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* fix(tests): use cfg!(tarpaulin) to skip racy tracing-capture tests under coverage

under_tarpaulin() was keying off CARGO_TARPAULIN_VERSION, but
cargo-tarpaulin doesn't set that env var (verified locally with v0.35.4),
so the skip never fired and internal_error_logs_capture_underlying_detail
panicked under the Coverage CI job. cargo-tarpaulin compiles with
--cfg=tarpaulin, so cfg!(tarpaulin) is the reliable detection. Add the
matching check-cfg lint config so the cfg name passes -D unexpected_cfgs.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* fix(booking): soften limit-reached page wording for guests

"Event type has reached its booking limit for the current period" leaks
host-side jargon onto the guest. Use a phrase the guest will actually
parse: the meeting is full, try a different date.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* fix(booking): don't call a frequency-capped day "fully booked"

"Fully booked" implies sold-out capacity; here the host just configured
a per-period cap. Reword so the guest understands it's a host setting,
not exhausted availability.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
huntervcx pushed a commit to DYB-Corp/calrs that referenced this pull request Jun 25, 2026
Minor release with two themes: closing the 1.10.2 sync-robustness
hotfix loop (the three follow-ups filed against olivierlambert#105 / olivierlambert#106 / olivierlambert#107)
and turning the booking-frequency-limits surface from a half-wired
feature into a real one — first by hiding capped slots in the picker
(olivierlambert#116), then by adding per-team-member caps (olivierlambert#118).

Highlights:
- Sync robustness: HEAD-check resource before cancelling (olivierlambert#108),
  scope cancel_orphaned by source/account (olivierlambert#111), propstat-aware
  parser ignores property-level 404s (olivierlambert#109).
- Booking frequency limits: team event type save/load fixed and
  limit-reached page styled (olivierlambert#114); slot picker hides capped periods
  (olivierlambert#116); per-member opt-in flag with full picker/submit/round-robin
  enforcement (olivierlambert#118).
- Migration 051 adds booking_frequency_limits.per_member.

650 tests total, up from 634 in 1.10.2. See CHANGELOG.md for details.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
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.

1 participant