- Shipped
- August 14, 2026 at 4:04 PM UTC
- Author
- kamo
- Commit
- 13abf00
Two things, both about a calendar event being a poor place to keep a copy of somebody else's record. The event dialog now reads the lead from the CRM. Its name, the number to ring, the email, the best time to call — all fetched when the dialog opens, keyed by the callback id the event already stores. What it does not do is show a copy frozen at the moment the call was booked, which is what the description used to carry and what would have quietly told a member to ring a number nobody had answered in weeks. The description is now the member's own note and nothing else, which cannot go stale because it was never a copy of anything. And a pending call can be opened from the lead page. Clicking one reopens the same calendar event in the same dialog, so the place a member goes to look at a promised call is the place they can move it. Saving goes through SecurityService rather than the calendar API, because the callback record and the event are two views of one promise and only the service that owns both can move them together — the alternative is a lead page and a calendar that disagree about when the call is, and a reminder that fires against whichever the member is not reading. The row itself is the control; the resolve buttons beside it stop the click, so nobody marks a call contacted while meaning to read it.