Content
View differences
Updated by Jens Ulferts almost 6 years ago
### General description
I have a local installation configured to send e-mail notifications directly with SMTP. The e-mail settings themselves are correct, but the server is temporarily refusing connections. The openproject server complains of an internal error for a few actions when the settings point to SMTP, but the same actions work flawlessly when the notifications are changed to sendmail method (even though I don’t get the e-mails because of the server, which is a completely unrelated matter)
### Output
On certain actions (such as changing a user’s password), I get the following output:
Internal error
An error occurred on the page you were trying to access.
If you continue to experience problems please contact your OpenProject administrator for assistance.
If you are the OpenProject administrator, check your log files for details about the error.
Back
Upon checking the logs, no message indicates anything useful, let alone anything related to e-mail notifications.
### Expected
What I expected was for openproject to store the e-mail notifications in an internal queue and retry later returning successfully now; or even to fail immediately, but with a useful message explaining what happened.
### Reproducibility
Always reproducible. Changing e-mail notification settings to a refusing server through direct SMTP causes that undescriptive “internal error” whereas changing them to sendmail causes openproject to work as expected (albeit without the e-mail notifications, which I already expected).
### Related bugs
This seems very much related to the \#16398 bug report, though I haven’t tested other user settings for notifications to make sure I cover the same use cases.
### Followup
I’ll be very content to receive a descriptive message indicating the cause of the issue in the error page or in the logs about the issue. I’ll be happier if the direct SMTP method behaves like a MUA and stores the unsent e-mails for transmission retries, possibly showing the administrator in the web interface the send queue when it stalls. But I understand that’s more a job for sendmail itself.
Thanks
I have a local installation configured to send e-mail notifications directly with SMTP. The e-mail settings themselves are correct, but the server is temporarily refusing connections. The openproject server complains of an internal error for a few actions when the settings point to SMTP, but the same actions work flawlessly when the notifications are changed to sendmail method (even though I don’t get the e-mails because of the server, which is a completely unrelated matter)
### Output
On certain actions (such as changing a user’s password), I get the following output:
Internal error
An error occurred on the page you were trying to access.
If you continue to experience problems please contact your OpenProject administrator for assistance.
If you are the OpenProject administrator, check your log files for details about the error.
Back
Upon checking the logs, no message indicates anything useful, let alone anything related to e-mail notifications.
### Expected
What I expected was for openproject to store the e-mail notifications in an internal queue and retry later returning successfully now; or even to fail immediately, but with a useful message explaining what happened.
### Reproducibility
Always reproducible. Changing e-mail notification settings to a refusing server through direct SMTP causes that undescriptive “internal error” whereas changing them to sendmail causes openproject to work as expected (albeit without the e-mail notifications, which I already expected).
### Related bugs
This seems very much related to the \#16398 bug report, though I haven’t tested other user settings for notifications to make sure I cover the same use cases.
### Followup
I’ll be very content to receive a descriptive message indicating the cause of the issue in the error page or in the logs about the issue. I’ll be happier if the direct SMTP method behaves like a MUA and stores the unsent e-mails for transmission retries, possibly showing the administrator in the web interface the send queue when it stalls. But I understand that’s more a job for sendmail itself.
Thanks