osticket / Tickets / #4760 Delay with new task being shown, error message in logs

Anonymous - 2019-02-26

Originally posted by: JediKev

@AnonTester

Unfortunately, I'm unable to reproduce the same with osTicket v1.11, PHP v7.2, NGINX, and Firefox. I see that the line of code the error is referring to includes the $_SESSION[':form-data'] variable which is form-data we store in the session. Is your browser doing something funky with sessions? Have you tried a different browser such as Chrome?

Cheers.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2019-02-26

Originally posted by: AnonTester

Same problem with Google Chrome.
However, I figured out what's causing the issue:
When clicking on the task tab once, the address bar URL remains the same and a task can get added and the page refreshes properly showing the new task.
However, when clicking on the task tab a second time, the address bar URL changes to:
.../scp/tickets.php?id=xxxxx#tasks
In this state, trying to add a new task will result in the page not refreshing and the php error appearing in the logs.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2019-02-26

Originally posted by: JediKev

@AnonTester

Yea, I cannot reproduce this. I will have to try on my other installation.

Cheers.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2019-02-26

Originally posted by: JediKev

@AnonTester

I tested this with all my installs of v1.11 (both upgraded and blank installs) and cannot reproduce your issue. I have some hosted with Apache/PHP 5.6 and some hosted with NGINX/PHP 7.2 and cannot reproduce this issue at all.

At this point we'd need some related errors from your Apache error logs, PHP error logs, browser console logs, and/or osTicket system logs to assist.

Cheers.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2019-02-26

Originally posted by: AnonTester

Browser console output based on:

Opening existing ticket

Clicking on tasks twice (so URL contains the anchor tasks)

Cleared all existing errors in console
Output after clicking on add and filling in all fields:
ReferenceError: reference to undefined property "data"[Learn More]
scp.js:687:5
ReferenceError: reference to undefined property "event"[Learn More]
redactor.min.js:1:59270
ReferenceError: reference to undefined property "t"[Learn More]
redactor.min.js:1:144934
ReferenceError: reference to undefined property "tagName"[Learn More]
redactor.min.js:1:136900
ReferenceError: reference to undefined property "tagName"[Learn More]
redactor.min.js:1:170599
ReferenceError: reference to undefined property "blurCallback"[Learn More]
redactor.min.js:1:25609
ReferenceError: reference to undefined property "_lastInput"[Learn More]
jquery-ui-1.12.1.custom.min.js:10:15575
ReferenceError: reference to undefined property "type"[Learn More]
jquery-3.3.1.min.js:2:67502
ReferenceError: reference to undefined property "duration"[Learn More]
jquery-ui-1.12.1.custom.min.js:13:10316
ReferenceError: reference to undefined property "uiBackCompat"[Learn More]
jquery-ui-1.12.1.custom.min.js:13:14901
ReferenceError: reference to undefined property "easing"[Learn More]
jquery-ui-1.12.1.custom.min.js:13:25006

At this point the new task doesn't show up, but it has been created. Refreshing the page will show the task.

Test repeated with refreshed ticket view without the anchor tasks in the URL results in no javascript errors at all and the page displays the newly created task immediately.

No other errors in apache's log file except for the reference to line 1459 as per initial post.

I repeated the test with osTicket system logs set to DEBUG, but no entries are recorded.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2019-02-26

Originally posted by: JediKev

@AnonTester

Okay, so by "URL contains the anchor tasks" I assume you mean the URL has #tasks on the end, right? If so, I'm not seeing the same thing. Where and when did you download v1.11?

Cheers.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2019-02-26

Originally posted by: AnonTester

downloaded and installed it on 19 Feb from the official website. Selected osTicket 1.11, storage-fs plugin and en-GB language pack.
Exact download link as per browser history:
https://s3.amazonaws.com/downloads.osticket.com/downloads/osTicket-v1.11-651c3b51104cefd927e18449fbea9859.zip?response-content-disposition=attachment%3B%20filename%3DosTicket-v1.11.zip&AWSAccessKeyId=AKIAIIYNNTPTQ5Z447SA&Expires=1550613129&Signature=vZ2Qd3Zddx64KdU%2BBOrT0p7fVAo%3D

renamed to ost.zip, unzipped, overwrote my 10.4 install with the upload folder, moved storage and language phar file into the appropriate folders, adjusted the permissions and let your update function do the rest.
Only adjustment was to apply the change to include/class.search.php as per https://github.com/osTicket/osTicket/issues/4720 to get it to create tickets from emails.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2019-02-27

Originally posted by: ntozier

I would recommend that you nuke the database.
Download the archive from osticket.com/download (just the archive).
reinstall.

Then once it's up and running see if you have the same issue.

After that introduce the plugin. Test.
After that introduce the language pack. Test.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2019-02-27

Originally posted by: AnonTester

@ntozier , I can't see how nuking the database and overwriting the files has anything to do with the javascript errors on the Task creation dialogue only when an URI anchor is present. osTicket correctly creates the task, but doesn't refresh and display the created task in this situation and a full page refresh is required.

If there were any db issues, surely this would have been displayed in the osTicket system logs on DEBUG level or caused other errors in the apache logs.
We can also rule out any issues with the files as the downloaded package was a zip file inside a zip file meaning CRC checks have been done twice while unzipping each of them. What difference should a redownload make?

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2019-02-27

Originally posted by: ntozier

You told us that you installed osticket and a language pack at the same time. Doing is known to causes issues. Unless this was fixed? (@JediKev)

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2019-02-27

Originally posted by: JediKev

@AnonTester

Just curious, have you tried the fix suggested here?
https://github.com/osTicket/osTicket/issues/3197#issuecomment-439988720

Don't use 800 though, just to test use something massive like 5000.

Cheers.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2019-02-27

Originally posted by: AnonTester

@ntozier it was an upgrade, not a new install. However, while I intended to upgrade with the language pack at the same time, I moved the language file in the wrong folder and moved it after the upgrade (no language pack present before the upgrade at all). As an additional test, I switched to default English US, but same issue.

@JediKev, I've just tested it with a value of 6500, no change. Same javascript errors while interacting with the form, saves the data, but doesn't update the task list.

Here's the full console output and all errors when on the task tab and doing a full refresh (F5), then proceeding to add a task and clicking through the fields. Maybe this might help and a previous error might give a clue about this odd issue?:
osticket1.11_task_issues.txt (github.com)

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2019-02-27

Originally posted by: JediKev

@AnonTester

It's complaining about syntax errors and reference errors with jQuery and jQuery UI. jquery-3.3.1.min.js and jquery-ui-1.12.1.custom.min.js were both downloaded directly from jQuery's website so I doubt there are any issues with these. I cannot replicate this issue so it makes me think it's something with your server/environment/browser.

Cheers.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2019-02-27

Originally posted by: ntozier

@AnonTester Ah I missed where you said that this was an upgrade. (It sounded like a fresh install.)

To rule out the DB maybe setup a temp test site on your server and use a fresh db. If the problem still occurs then you know its not the data.

Are you running CentOS per chance? (If yes how about SELinux?)

What web browser are you running?
Does your browser have any script manager plugins/extensions [like Tampermonkey, noscript, etc]?

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2019-02-27

Originally posted by: AnonTester

Server is running Debian 9.8 with Apache/2.4.25 and php 7.0.33-0+deb9u1, no non-debian repositories

Browser or system accessing it can be ruled out completely: I've tested both with Firefox and Chromium (no script manager extensions) on a Linux Mint Debian Edition 3 system. Additionally I just tested it from my Android mobile. Same issue on all of them.

Tested on my backup server, exactly the same versions of apache and php and Debian, only difference is that it's a 32bit system and not a 64bit system. Same issue.

The databases of the two servers are the same (multi-master replication) though. I still can't see how or why the db should play into this though as the task is being properly inserted into the db and the only difference between the the page showing the created task and the page not showing it is the javascript errors when the URL contains the #tasks anchor.

I'll see what I can do in terms of setting up a secondary install with different db, but that may take a wee while.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2019-02-27

Originally posted by: JediKev

@AnonTester

Maybe it's something with Debian?? I'm using almost exact same setup but instead of Debian I run CentOS and instead of PHP 7.0 I'm using PHP 5.6.

Cheers.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2019-02-27

Originally posted by: ntozier

I'll try to find some time to setup a test site on my Debian 9.8 box tomorrow. But Works been really busy lately so I'm not confident I will get to it tomorrow.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2019-03-01

Originally posted by: alwinkpc

Same problem here. Tested resetting ost-config.php and creating a new database (osTicket v1.11). All works!
What could be issuing this error at javascript level? I'm digging into this following the same error on xampp/windows and docker image php:5.6/ubuntu

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Delay with new task being shown, error message in logs

Milestone

Searches

Help

#4760 Delay with new task being shown, error message in logs

Prerequisites

Description

Versions

Server Information

Discussion