Mails not always send after upgrade to 4.4

Had 4.2.X (latest) here working without any problems. Now upgraded to 4.4.2 and sometimes when doing correspondence no mail is send.

There is “Correspondence added” in ticket view but there is no “Outgoing email recorded” entry.
When that happens nothing is written to log. Mail is not send silently.

Users reporting the problem were using firefox and opera.

Was looking into git in case if there was some fix that could be related to this problem but didn’t find any.

What could be the problem?

Hi Arkadiusz

Can you help me im just upgraded my RT to 4.4.2 and had a problem when generating user, group access, it says “Page isnt working” i think i missed some configurations.

Attached here screenshot

Thank you

Could me problem be related to this commit? Like this fix not always working properly. I don’t know - some timing issue etc?

commit 94bee42b8a00631519b16e2bfda1d29a3908aa7b
Author: Shawn M Moore shawn@bestpractical.com
Date: Tue Mar 14 17:46:37 2017 +0000

On form submit, explicitly re-enable PreviewScrips checkboxes

Otherwise we inadvertently suppress all outgoing email, since the
disabled checkboxes are excluded from the form submission.

Looks like someone else reported the same thing:
https://issues.bestpractical.com/Ticket/Display.html?id=33198
and provided a patch but it seems to be doing (almost; changes these fields earlier, so that could be important) the same thing as
commit 94bee42b8a00631519b16e2bfda1d29a3908aa7b that’s already in 4.4.2

Arkadiusz, we’re looking at the same issue, and it seems indeed like it has something to do with the jquery on update.html. I can also report that it occurs in Chrome, as I experienced it earlier today.

The last patch you link to does somewhat the same thing, but at a different point in time. Commit 94bee… handles checking the boxes on submit, while the patch handles checking boxes during the ajax call(which is triggered by updates on the cc/bcc fields and ticket stats). However, the patch mentions cases where you type something and then click on a checkbox - our users have experienced this just by typing something then clicking on submit, so it should only be one call to updateScrips if I understand correctly.

Thus, the working theory we’ve had is the following; when you click on submit, updateScrips is triggered because of the onBlur event that’s bound to UpdateContent. However, due to javascript, updateScrips is run after the onSubmit event. This is fine if updateScrips completes before the form is submitted, but updateScrips is only run partially on rare occasions, meaning that it only gets to return the boxes, but not check them.

I’m currently working on a fix. The obvious one seems to be to remove updateScrips from UpdateContent, but then a callback should be added to ensure that recipients are up to date. Another could be to remove updateScrips from UpdateContent as above, then add synchronous calling of updateScrips and checking of recipients.

Disclaimer: Note that my knowledge about the inner workings of javascript is lacking, so I may be off the mark.

FYI

With patch from Login
the issue is gone.

No errors in last 25 hours where usually there were like 10-15 missing outgoing emails (we have a script that monitors that for us).

Well not fully gone with that patch but now occurs very rarely (like once per a week).

Is anyone from rt team working on this nasty issue?

Could you try applying the following patches on the original RT 4.4.2’s share/html/Ticket/Update.html and see if could solve the whole issue?

It’s https://github.com/bestpractical/rt/commit/db6ef53164cc03d9e696f21664da0c092617b4bd.diff and Login

Thanks!

Had first patch, so applied second, too.

Unfortunately doesn’t fix it for me. I still get corespondence recorded in rt but no outgoing email (and no record of outgoing email in ticket history obviously).

I assume you cleared mason cache and restarted web server before testing it?

Also, did you notice that the recipients checkboxes were “unchecked” when submitted the form?

Unfortunately these were not my corespondence, so don’t know (and these users also don’t remember). I monitor entire rt to catch cases like this though.

And yes, mason cache was cleared and fcgi server restarted.