Skip to content

Add Rippling OOO to project timeline - #410

Merged
redreceipt merged 1 commit into
mainfrom
agent/add-rippling-ooo-timeline
Jul 27, 2026
Merged

Add Rippling OOO to project timeline#410
redreceipt merged 1 commit into
mainfrom
agent/add-rippling-ooo-timeline

Conversation

@redreceipt

Copy link
Copy Markdown
Member

What changed

  • Added a read-only Rippling iCalendar client for the private direct-reports PTO feed.
  • Added striped OOO bars to the six-week project timeline, sharing lanes with overlapping projects.
  • Supports full-day and timed/partial-day events, including iCalendar's exclusive DTEND semantics.
  • Shows direct-report calendar coverage and a non-blocking unavailable state.
  • Documented the required secret URL and optional display-time-zone configuration.

Why

The project timeline needs OOO visibility, but Rippling developer API access is not available. The existing direct-reports calendar subscription provides the dates needed for this view without requiring API credentials.

Security and privacy

  • The subscription URL is environment-only and is never committed or logged.
  • Requests are restricted to Rippling's HTTPS PTO calendar path, do not follow redirects, use a timeout, and cap response size.
  • Calendar descriptions and leave details are ignored; the UI renders only a fixed OOO label and dates.
  • Ambiguous first-name matches are skipped to avoid assigning one person's PTO to another row.
  • The feed does not expose approval state, so published calendar events are treated as authoritative.

Deployment

Set RIPPLING_PTO_CALENDAR_URL to the private Rippling calendar subscription URL. Optionally set RIPPLING_PTO_TIMEZONE (default: America/New_York) for timed entries.

Validation

  • ruff check .
  • ruff format --check .
  • mypy .
  • python -m unittest discover -s tests -p 'test_*.py' (121 tests)
  • vulture . --config pyproject.toml
  • Headed browser render with synthetic full-day and partial-day PTO, including overlap with a project bar

@redreceipt
redreceipt temporarily deployed to bug-board-agent-add-rip-ohsvdu July 24, 2026 19:57 Inactive
@redreceipt
redreceipt marked this pull request as ready for review July 27, 2026 11:51
@redreceipt
redreceipt merged commit 4caf017 into main Jul 27, 2026
5 checks passed
@redreceipt
redreceipt deleted the agent/add-rippling-ooo-timeline branch July 27, 2026 11:51

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: df8f2c57e8

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment thread rippling_pto.py
events: list[PTOEvent] = []
current_event: dict[str, tuple[dict[str, str], str]] | None = None
invalid_event_count = 0
captured_properties = {"UID", "SUMMARY", "DTSTART", "DTEND", "STATUS"}

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Honor DURATION when deriving PTO end dates

When a Rippling VEVENT uses the valid iCalendar DURATION property instead of DTEND, this allowlist discards it and _event_from_properties falls back to end_datetime = start_datetime. Multi-day or overnight PTO encoded that way is therefore rendered as a single-day event; capture and apply DURATION as the alternate means of calculating the event end.

Useful? React with 👍 / 👎.

Comment thread rippling_pto.py
Comment on lines +256 to +257
if len(response.content) > MAX_RIPPLING_PTO_CALENDAR_BYTES:
raise ValueError("Rippling PTO calendar response is too large")

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Enforce the response limit while streaming

When Rippling returns an unexpectedly large or highly compressed response, accessing response.content has already downloaded and decompressed the entire body before this size check runs. The advertised 1 MB cap therefore cannot protect the web worker from excessive memory use; request the response in streaming mode and stop reading once the limit is exceeded.

Useful? React with 👍 / 👎.

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