feat(notifications): carry what people wrote into the notification an…

[karlitschek]

…d the email

The comments an employee, manager or HR leave on a request are the substance of the workflow — the reason for asking, the reason for refusing, the question that holds a decision up — and until now almost none of it left the database. A comment produced no notification and no email at all, so it existed only behind the request's Comments tab, which nobody opens unless they already know there is something to read. A manager's question could sit unanswered until the request escalated on a timer.

Adding a comment now notifies and mails the other people on the request: the employee and their line manager, plus HR once the request has been escalated and they are a party to it. The author is never notified of their own comment.

The same text is now carried by the messages that already existed, attributed to whoever wrote it:

• new request / escalation / reminder — the applicant's reason, which the manager was previously asked to decide without;
• approved — the manager's approval note, which was dropped entirely;
• rejected — the reason, which reached the email only, glued into the middle of the summary sentence, and never the notification;
• withdrawal declined — the refusal reason, in place of the previous "See the comments on the request for the reason."

The email quotes the text in full via addBodyListItem, which escapes it and keeps its line breaks, so a comment written as several paragraphs still reads as several paragraphs. A notification renders on one line and its parameters are copied to every recipient's row, so it carries a whitespace-collapsed 200-char opening instead; where a note is present it replaces the message boilerplate, because "Review it in Absence." says nothing the Review button does not while the reason is the reason to look at all.

The replacement is the one deliberate exception: they are told the dates and nothing else. Cover duty does not come with a right to read a reason that may be medical, and a test pins that.

Notifications stored before this change have neither parameter, so the notifier reads both defensively rather than failing to parse an old row.

For the server log, comment bodies and decision comments were already there as detail. The gap was the applicant's own reason, which was never logged at all; it now goes into the request_created context as reason. Deliberately not into detail — that feeds the per-request history timeline, where the Details tab already shows the reason and a second copy would just be noise.

🤖 AI (if applicable)

• The content of this PR was partly or fully generated using AI