feat(web,api): add an opt-in switch for the dormant Jira background poll (make the personal pull actually continuous)
Context
Follow-up from #3089 (closed)/!2130 (merged)'s roadmap correction, and the real residual scope from #3090 (closed) (closed as already-delivered — the on-demand personal Jira pull, connections, and My Work surfacing all exist).
What's genuinely unbuilt: integrations.poll_external_sources (ADR-0097 §4) exists and runs on a */15 beat schedule, but polling is default-off per connection (config["poll_enabled"]) and there is no UI anywhere to turn it on — grep -rn 'poll_enabled\|pollEnabled' packages/web/src packages/web/e2e returns zero hits. The task's own docstring calls it "a wired-but-dormant hook — it fans out zero pulls today." So today's Jira integration is on-demand (connect + "Sync now"), not continuous, despite the backend piece existing.
Proposed scope
- A toggle on the Connected Accounts page (
ConnectedAccountsPage.tsx/ExternalSourceConnectDialog.tsx) to opt a connection into background polling - Wire it to
config["poll_enabled"]via the existing connection PUT endpoint — no new endpoint needed if the field is already accepted server-side (verify) - Confirm rate-limit/backoff behavior (429/
Retry-Afterhandling already exists per ADR-0097) holds up under always-on polling rather than on-demand bursts - Update
overview/roadmap.md's 0.4 Jira bullet once this ships, to drop "wired but deliberately dormant" and describe the poll as available
Gates
rbac-check if the PUT payload/permissions need any change; regression-check always. Likely small enough to skip architect/threat-model re-runs since ADR-0097's STRIDE model already covers polling — confirm the existing threat model's assumptions still hold for always-on rather than on-demand before shipping.