- Shipped
- September 7, 2026 at 1:19 AM UTC
- Author
- Kamo
- Commit
- 1705452
The callback dialog hid the invite controls, and the note under it said "The lead is not notified." That was true, and it was the right call for the control being hidden: that one asks about a guest LIST — who is on it, and by which of two routes each of them hears. A callback has one person on the other end of it, and offering three controls to answer a one-answer question is why nobody asked for it. So the guest section stays hidden and this asks the single question instead, in the lead's own terms, with the address it would go to written out beneath it. Ticked, the lead gets the organisation's branded letter with an .ics attached, sent from the member's own address so a reply reaches whoever is going to ring them. Off by default even when the lead has an address. Writing to a customer is something a member asks for, not something that happens because they opened a dialog. The address is shown rather than implied, because "email the lead" hides exactly the mistake that is invisible until it has been made: a lead whose address was corrected last week, or one who never had a usable one. Where there is no address the box renders disabled and says so, in the same amber the guest section uses when a route is closed — a member who believes they invited somebody and did not is the failure this control exists to prevent. Reopening a callback shows the state it is actually in, read off the event's own guest rows rather than a stored flag. Un-ticking is a real instruction and travels as one: the payload always carries notifyLead, true or false, because the service reads an absent value as false and acts on it — a payload that omitted the field when the box was off would be indistinguishable from a client that never learned to send it, and un-ticking would silently do nothing while appearing to work.