Issue with outgoing E-mails and attachments

ADRD

Hello everyone,

I've been struggling with an issue since I updated to 1.17 regarding replies to tickets.

When I send a reply, like this :

As, we can see, it has an attachment, that I put there, and is kept in the ticket history from the agent side.
But when the customer receives it, it looks like that :

Empty from any attachment.

I see no errors either in and the file size limit is set to 200Mb on OsTicket as well as in PHP.

Here are some screenshots of my configuration :

I've tried that last one with and without "Required identification to see attachments", with no visible changes.

Attachments work perfectly the other way around, if a ticket is created through mail and the customer adds an attachment, it will show up in the history, as well as if they reply with one.

Here is what shows when I load any page on my osticket, nothing specific shows up when I send the mail, except for the green validation text on top of the page

Thanks in advance for your help and let me know if I can give you any more information

ADRD.

KevinTheJedi

ADRD

Upgrade to the tip of 1.17.x and retry.

Cheers.

ADRD

KevinTheJedi

Hey

What do you mean?

I see no newer release than the one I've already got on my installation; I upgraded mid-october and the latest release I see is from September 30th, and matches the version I got on my screenshot (1d8b790).

KevinTheJedi

ADRD https://github.com/osTicket/osTicket/issues/6295#issuecomment-1272563459

ADRD

KevinTheJedi

Did that, I see no difference. Mails are still sent without attachments.

I have another issue with assigning when fetching, which I opened another conversation for, and this didn't solve that either.

KevinTheJedi

ADRD

Then you can go to the GitHub repo and apply any relevant pull requests or wait for next release.

Cheers.

ADRD

KevinTheJedi

I can't just wait; my users need this to work properly.

I had to apply this pull to my tenant, earlier
https://github.com/osTicket/osTicket/pull/6296

I have another site on which I didn't because they didn't report any issue (maybe they don't have gmail customers), and on this site attachments work.

Do you think the above pull could break attachments? Do I need to choose between replying to gmail customers or replying with attachments?

KevinTheJedi

ADRD

No, that will not break attachments (unless you manually applied the changes and you broke something).

I cannot replicate this issue so I am unsure what's going on in your case. Do you have attachments disabled? Can you compare the settings from the working instance to the non-working instance? Have you checked your logs for any related errors? There are so many questions.

Cheers.

ADRD

KevinTheJedi

I took the two files from the pull and put them in the include folder, is that not the way to do it ?

Most of the questions you asked (about settings and logs) are answered in my original post.

As for the comparison, here is one difference I found

In non working environment :

(was set to noreply@...), changed it, still doesn't work

In working environment :

Also it looks like I don't have the full form on my other environment

KevinTheJedi

ADRD

I can't read that language but it looks like that is supposed to be the Email Attachments checkbox. You will need to check your logs for any related errors.

Cheers.

ADRD

KevinTheJedi
The setting says, roughly translated :

Attachments : [] Attached to user

It is in : Admin Panel -> E-mails -> Settings in the bottom

There is nothing in any error logs that is triggered when sending an attachment, nor on the web interface or directly on the server.

KevinTheJedi

ADRD

No, when that page breaks, there should be an error logged somewhere.

Cheers.

ADRD

[Wed Nov 02 16:20:57.391554 2022] [php:error] [pid 4251] [client 10.1.30.9:56995] PHP Fatal error: Uncaught Error: Call to a member function getName() on null in /var/www/osticket-tv/html/include/staff/settings-emails.inc.php:154\nStack trace:\n#0 /var/www/osticket-tv/html/scp/emailsettings.php(38): include_once()\n#1 {main}\n thrown in /var/www/osticket-tv/html/include/staff/settings-emails.inc.php on line 154, referer: https://osticket.mycompany.ch/scp/emails.php

KevinTheJedi

ADRD

Did you delete an email at some point? It seems as though it's trying to get a name for the email set for MTA but doesn't exist so it fails. Go to your database, go to config table, and set the value to 0 where the key is default_smtp_id.

Cheers.

ADRD

KevinTheJedi
I did remove some mailboxes because of the OAuth2 plugin that didn't show the configuration popup anymore.

The default_smtp_id is already set to 0

4.05pm today means about 50 minutes ago, but I don't know what exactly updated it, maybe when I changed the "noreply@..." to PHP funtion for the MTA.

KevinTheJedi

ADRD

Then check your database as it’s looking for an email that doesn’t have an SMTP account. Or if it does then the SMTP account is borked.

Or maybe there is an SMTP account but no system email to reference to. I think this will be the most likely.

Cheers.

ADRD

Those are the same ressource_owner_email I don't see SMTP related things but the fact that it's there twice under different email accounts makes me wonder if it could create a conflict ?

There is only one E-mail created with that info on OsTicket.

ADRD

So... I know this doesn't solve the source and it's a bit system D, but I managed to make it work by copying HTML code of the end of the form from the working instance to the other, checked the box and applied.

At least now my agents can send mails with attachments, thus I am less in a hurry to cleanup anything that would still be wrongly setup.

KevinTheJedi

ADRD

I truly don’t know how that would work as that doesn’t fix PHP errors but hey, whatever works.

Cheers.

ADRD

KevinTheJedi

I guess the PHP just doesn't load the page.

But I'd still like to fix it correctly if you can help me... Do you think the above mentionned seemingly duplicate database entry could be the cause of the problem ?

KevinTheJedi

ADRD

You'd have to look at what I mentioned above. ^

Cheers.