Attachments saved but not linked to ticket

visham

I am continuing and updating my thread I opened in osTicket 1.15.x, in this new 1.17.x thread
(https://forum.osticket.com/d/100861-attachments-saved-but-not-linked-to-ticket)

I am facing a problem with inserting attachment in threads or when creating a new ticket. Randomly in some cases attachments uploaded are missing in the thread.

osTicket Version: v1.17.3 (ca95150)
Web Server Software: Apache/2.4.56 (Fedora Linux)
MySQL Version: 8.0.30
PHP Version: 8.1.17
All PHP extensions installed and enabled. 

**Note: I have commented Lines 3975 to 3977 of class.forms.php to fix the http 500 issue with zip attachments.**

I replicated the problem:

1. I create a ticket with 3 attachments

2. After submission, only 2 attachments are visible.

3. In the ost_file table, the 3 files are present.

4. In the ost_attachment table, file with id 107 is not there and id 108 is duplicated : :.

KevinTheJedi

visham

Usually if you add an attachment, it uploads, and it doesn’t get attached it's due to session issues. Id try clearing your cache/cookies/sessions and try again. You can also try clearing out the records in the session table in the database (this will log everyone out) and restart Apache and PHP-FPM (if you’re running it) to clear any server-side cache.

Cheers.

visham

KevinTheJedi I tried the steps you mentioned, the problem is still the same.

@m4nii posted the same issue in the old thread (https://forum.osticket.com/d/100861-attachments-saved-but-not-linked-to-ticket).

KevinTheJedi

visham

Please do not cross-post.

Cheers.

KevinTheJedi

visham

How exactly do you replicate the issue? Upload files first, add a message, and immediately click send? Or upload files, add a message, wait for draft to save, and then click send? Add message first then upload files? Also, are you uploading all 3 files at once or one-by-one? I cannot replicate this so I need as detailed steps as possible.

Cheers.

m4nii

KevinTheJedi KevinTheJedi have you looked into my description of the problem - to me it seems that either the getField('attachments') or the getFiles() method does not work/parse properly. We assume some timeout or something else, where the form-id (or whatever is used to parse the attachments-field) changes. We atm turned on excessive debugging - which means we dump out the vars array in scp/tickets.php before and after the mentioned function calls. Everytime we're missing attachments on the messages the 'files' array of $vars is empty (as posted in the 'old' thread)

visham

@m4nii Thanks for updating

KevinTheJedi I have done several scenarios and uploaded screen captures of the events.

Scenario 1: (https://streamable.com/umob7t)

Add message first.
Upload files from “Choose Files”.
Do not wait for “all changes save”

Outcome 1: Erratic
a. First case all files missing
b. Second case all files uploaded successfully.

Scenario 2: (https://streamable.com/dwcp8m)

Upload files from “Choose Files”.
Add a message, wait for draft to save,
then click send

Outcome 2: Erratic
a. At times, not all attachments appear in thread

Scenario 3: (https://streamable.com/a3h8mv)

Add message first.
Upload files via “Drag n Drop”.
Either wait for “all changes save” or “ unsaved”

Outcome 3: Normal
a. All attachments appear in thread

The problem is not occurring when using “Drag n Drop” feature for attachment.

Scenario 4:

Add message first
Wait for ‘all changes save’
Attach documents individually or multiple selections from browse

Outcome 4: Normal
a. All attachments saved and appear in thread.

@m4nii can you try using drag n drop method only and check if you get any missing attachments.

*If the video links are dead, let me know I will re-upload.

KevinTheJedi

m4nii

Yes but it doesn’t help if I can’t replicate the issue.

Cheers.

visham

m4nii
Have you have the time to check if you get upload issues when using only the Drag and Drop feature?

visham

KevinTheJedi

For info, I am using Windows 10 PC and doing the tests on Microsoft Edge Version 112.0.1722.39 and Chrome Version 112.0.5615.87. Those are the latest versions available.

ItsMePasse

visham At least for us, the method of uploading an attachment doesn't matter. The problem occurs randomly and not for everyone. However, all employees use the same programs (current Windows 10 with current Chromium Edge) and current osTicket 1.17.3

There are no errors in the error log from the server, as with the others above.

ItsMePasse

Unfortunately, we also have this problem again and again with some of our employees. With some there are no problems, some report that either all file attachments are missing or only individual ones after the reply has been sent. Very annoying.

(all using Windows with the latest Chromium Edge)

DanHLJr

Experiencing the same issue as the others above. We are running v1.18 and have intermittent reports of attachments that appear to upload during a reply, but once you save/send, they are gone! Vanished. Like the upload never happened. (All agents are up-to-date Chrome. Server is current PHP 8.x Linux.) No sign as to WHY this happens here. It just DOES, and only once in a while, and this seems to plague certain random users more than others. No clue why its happening, but we've been running for about a month successfully, and now this just started. (It's quickly eroding trust in this system.) If we cannot trust the system, people will not continue to use it. Our agents are asking us to fix it ASAP or consider switching systems. (We have a provider/customer relationship with these users, so if we can't make this work 100%, we'll need to shop for a new ticketing solution. This is NOT good.)

Is there ANY clue as to why this continues to happen? (Clearly it's a wider-spread problem, as other osTicket installs are experiencing the same problem, and this particular issue has been reports since like v1.2 that I'm aware of, so it's YEARS old.)

I'd appreciate any help or insights, since as newer osTicket adopters (but a month in with nearly 1,000 tickets) we aren't sure how to proceed with these problems persisting.

Any thoughts/resolution at all???

KevinTheJedi

DanHLJr

You need to find a replicable case and see how exactly they are uploading, what they are uploading, etc.; essentially exact steps to replicate. You can also look at the Network tab in the browser's developer tools for the failed request and see what error it gives you. You should also have the people who can replicate try on a new browser with no browser extensions, etc. as the extensions can sometimes cause issues as well. You should also ensure you don’t have "Bind Agent Session to IP" setting enabled as this can sometimes cause session issues. You should also try increasing the Agent and User session timeouts in the system settings.

Cheers.

DanHLJr

Thanks Kevin!

I've disabled the Agent and User timeouts. (We actually have no users that aren't agents. Everything on the front-end is pretty much dead/disabled. We do email-only support.)

Unfortunately, it's not something I can easily reproduce. These are end-users in other locations reporting stuff after-the-fact. It's all completely intermittent, and honestly only happens rarely - I haven't seen it happen in person, but it happened today with a single user 3 or 4 times in a row, and that pretty much panicked everyone. (This is a trusted, competent user here, so we know what they are telling us is true.)

The human challenge here is that, "This doesn't happen with other systems." So these users are experiencing a failure that they DO NOT experience with any of the other systems they use daily.

I don't know what to say. I hope this session timeout thing fixes it. (And if it does, you should probably look into why it's happening with limited session timeouts...definitely a software issue in that case!)

A thought/note: We previously had a different timeout for User sessions than Agent sessions. The Agent timeout was longer. Could something regarding attachments be related to the user timeout? Like the Agent still has the session, but the attachment is tied to User timeout, so it fails??? (I say this, because when I tried to "close" the front-end by limiting User/front-end portal to only a certain IP through Settings, it did indeed BREAK attachments for Agents on the backend trying to download...they could not access the attachment URLs because the front-end was blocking their IP.)

It does seem that the system has at least that know issue, where agents should have been able to access attachments regardless of the front-end being "locked".

I hope this helps...

KevinTheJedi

DanHLJr

That’s because all file URLs point to the files.php file. You should’ve added an exception for this file for attachments to work for Agents.

User sessions are only tied to Users and are completely separate from Agents.

We have reports of session issues which we are actively looking into.

Cheers.

erikpahlberg

KevinTheJedi Wanted to let you know that I configured agent session timeout to 0 on 18.12.2023 and since then no errors have been reported to me.

DanHLJr

Thanks for the heads-up on needing an exception for the files.php when blocking the front-end by limiting IPs. Look forward to hearing a solution on the session issues, which hopefully resolves the problem with file attachments occasionally just getting "lost" when replying to tickets. (EDIT: Adding, "In the meantime, I've just disabled session timeout - set to 0 - to see if that resolves it, at least temporarily.")

erikpahlberg

DanHLJr
Have you had any more errors after configuring session timeout to 0? I have also been getting reports of this issue happening randomly.

hsaartet

FYI, we are experiencing this too.
Attempting the Agent Session Timeout = 0 now, it was previously set to 43830.
We have multiple agents having this, its intermittent, we use firefox,

osTicket Version 1.18-git
Web Server Software Apache
MySQL Version 10.6.16
PHP Version 8.2.15

hsaartet

hsaartet
fyi, i'll add that i also use the save to file system add-on rather than the database save