- Ya
- 5 Agosti 2026, 00:11 UTC
- Mwandishi
- Kamo
- Ahadi ya
- 02a73cf
An approver can now hand an opportunity to a different agent. The requester is never rewritten — applyPrimaryAgent records the move as its own history row with both names, so six months later the record shows that it moved rather than reading as though the new agent asked for it. Extension ownership, the lead-header control and the detail mask all follow the holder now; the "Agent" filter matches EITHER end of a reassignment, because hiding it from the agent who found it and from the agent who holds it are both wrong answers. Nine notifications cover the lifecycle. Requests and extension requests go to everyone who can decide them — both decision rights, since a member who can only deny would otherwise never learn a request exists to deny. Decisions and edits go to the holder, the original requester when that differs, and every colleague on a commission split; an edit additionally mails whoever it displaced, because losing a commission share silently is exactly what these emails are for. Two things are load-bearing in how the send is sequenced: - Resolution and rendering happen EAGERLY, inside the caller's transaction, while the entity still holds the values the email is about. approveExtension() clears the extension fields immediately after, so a later read would describe "no additional time" on an email whose subject is how much time was granted. - The SENDING waits for **************** Announcing a decision that a later failure rolls back would leave agents holding an email for an approval that never happened, and afterCompletion rather than afterCommit means the database connection is released before the outbound HTTP starts. Detail-table values are escaped at the point they enter the map: member names are org-entered free text, the table is injected as raw HTML, and the renderer escapes nothing. An edit that changes nothing sends no mail, and a PENDING reservation sends no "updated" — nobody has been told it exists yet. 60 tests.