Screen Resolution Bug

[FormidableMulk]

I upgraded from v2.42 to v2.5 this morning...


I am unable to submit tickets via the ticket submission form after the update.

MySQL Error
Incorrect integer value: '' for column 'screen_resolution_height' at row 1

Digging into the problem, it looks index.php is trying to use jQuery to change the values of two hidden form inputs that haven't been created. I reused the following snippet that I found a few lines later to create the missing HTML elements:

Code: Select all

<input type="hidden" id="screen-resolution-height" name="screen_resolution_height">
<input type="hidden" id="screen-resolution-width" name="screen_resolution_width">

Note: I haven't tested this with JavaScript disabled. This, presumably, wouldn't resolve the issue since we'd be trying to insert a not-integer value into an integer MySQL column. (Of course, there could also be other, bigger issues with JavaScript disabled.)



I am unable to POP3 scrape tickets.
hesk_pop3.php connects to the remote mailbox and checks for messages.

MySQL Error
Incorrect integer value: '' for column 'screen_resolution_height' at row 1

This could probably be addressed in several ways. I'm addressing it via inc/posting_functions.inc.php.

I changed

Code: Select all

'" . hesk_dbEscape($ticket['user_agent']) . "',
'" . hesk_dbEscape($ticket['screen_resolution_height']) . "',
'" . hesk_dbEscape($ticket['screen_resolution_width']) . "'
)
");

To this

Code: Select all

'" . hesk_dbEscape($ticket['user_agent']) . "',
" . ($ticket['screen_resolution_height']==""?"null":"'" . hesk_dbEscape($ticket['screen_resolution_height']) . "'") . ",
" . ($ticket['screen_resolution_width']==""?"null":"'" . hesk_dbEscape($ticket['screen_resolution_width']) . "'") . ")
");

Obviously POP-scraping will never be able to use the screen resolution detection features, but I built-in a conditional check to see if there was a value set for these index keys in case other functions relied on posting_functions.inc.php.

[mkoch227]

Are you unable to submit tickets on the customer interface, staff interface, or both?

Looking at the JavaScript, the hidden elements are created before the script is created, so there shouldn't be any missing elements when the JS is executed.

[FormidableMulk]

This was on the customer interface side. I didn't try the staff side before making my changes.

I saw the JavaScript snippet updating the hidden inputs' values in two sections -- both conditions of the if/else check for $hesk_settings['submit_notice'] --, but the HTML elements only existed in one of them. Adding the HTML elements to the other condition took care of the problem for me.

I'm still looking for other bugs, but these are the only two issues I've found so far -- and several other things that I had noticed that were off about 2.42 seem to be working in 2.5!

I'm about to ask my team to create a few sample tickets to see if they encounter any unexpected workflow breaks. I'll keep you posted.

[mkoch227]

Ah, that would be the issue. I only ran my tests without the submit notice showing, so the markup was was being added to the page. I'll add that to a quick fix for 2.5.1. If everything goes to plan, I should have that release out within a day or so. (Along with the POP3 fetching / email piping issue)

[mkoch227]

This should be fixed in 2.5.1. Let me know if there are still issues.