eTicket Issue Tracker Syndication Feed

Attachment not saved when ticket contains just an attachment

2009-04-29T18:58:32Z

Bug ID:	47
Summary:	Attachment not saved when ticket contains just an attachment
Product/Component/Version:	eTicket - Community/1.7.3
Status:	Unconfirmed
Severity:	Minor

Scenario:
- Report by mail
- Mail has subject, but no body text
- Mail has an attachment

Ticket is created, but attach is lost.

Error in mysql syntax when responding to ticket with blank body text

2009-03-28T20:16:57Z

Bug ID:	36
Summary:	Error in mysql syntax when responding to ticket with blank body text
Product/Component/Version:	eTicket - Community/1.7.2
Status:	Confirmed
Severity:	Minor

Send email to support email address, a subject line but no body text, then attempt to send a reply to the customer via the eticket interface.

When responding to a ticket with a subject line, but no body text, pressing the reply button generates the following error:

WARNING: Failed You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '' at line 1
WARNING: Could not post your message.

Looking at the database, there is no record created in ticket_messages table when an email with a blank body text arrives, so when replying, there isn't a message to reference when creating a reply in ticket_answers.

automail.php at cron running at 1 minute level, generating multiple ticket numbers

2009-03-28T20:16:04Z

Bug ID:	46
Summary:	automail.php at cron running at 1 minute level, generating multiple ticket numbers
Product/Component/Version:	eTicket - Community/1.7.3
Status:	Unconfirmed
Severity:	Critical

Hi,
I am wondering if I am the only one getting the problem.
When I run the cron job to execute automail.php at 1 minute, it generates 3 different ticket numbers for one email I sent to eticket system.
If I adjust cronjob to run>2 minutes, the problem goes away.
It looks to me that there is a racing condition in either automailer or eticket system.

If anyone knows how to solve it, it will be great

Windows live mail priority settings are ignored

2008-11-17T06:32:07Z

Bug ID:	45
Summary:	Windows live mail priority settings are ignored
Product/Component/Version:	eTicket - Community/1.7.3
Status:	Unconfirmed
Severity:	Moderate

Another small bug... summary is self-explanatory... neither low nor high priority settings in windows live mail are working.. Simple fix below

---
Old code (~ line 95 of pipe.php)

if ($parse->importance == "high") {
$pri = 3;
} elseif ($parse->importance == "low") {

---
New Code

if (strtolower(trim($parse->importance)) == "high") {
$pri = 3;
} elseif (strtolower(trim($parse->importance)) == "low") {

Windows live's headers use 'Low/High' as opposed to 'low/high' (case sensitivity issue)

Email Header Priorities are reversed

2008-11-17T06:29:06Z

Bug ID:	44
Summary:	Email Header Priorities are reversed
Product/Component/Version:	eTicket - Community/1.7.3
Status:	Unconfirmed
Severity:	Moderate

When using the email clients built in priority feature when opening a new ticket, the ticket gets created with the opposite priority to the one that was selected.

I.e. user sends email to support@company.com using a highest priority setting. Ticket gets created with a 'low' priority setting. Vice versa for a low priority email.

The fix is very simple, as it was likely a typo.

-----
Old code ( ~ line 95 of pipe.php)

if ($parse->importance == "high") {
$pri = 3;
} elseif ($parse->importance == "low") {
$pri = 1;
} elseif ($parse->priority == 1 or $parse->priority == 2) { // these got reversed
$pri = 1;
} elseif ($parse->priority == 4 or $parse->priority == 5) { // reversed got these
$pri = 3;
} else {
$pri = 2;
}

-----
New Code

if ($parse->importance == "high") {
$pri = 3;
} elseif ($parse->importance == "low") {
$pri = 1;
} elseif ($parse->priority == 1 or $parse->priority == 2) {
$pri = 3;
} elseif ($parse->priority == 4 or $parse->priority == 5) {
$pri = 1;
} else {
$pri = 2;
}

Invalid URL's Created when using brackets "["

2008-11-12T21:05:50Z

Bug ID:	43
Summary:	Invalid URL's Created when using brackets "["
Product/Component/Version:	eTicket - Community/1.7.3
Status:	Unconfirmed
Severity:	Moderate

I'm sure that you guys are making modifications to this, but I wanted to let you know anyway just in case.

When you respond to tickets (via email or web), eTicket is creating links whenever you use brackets. You can duplicate this on demand and have been able to since 1.5.7 or so.

1. Open a new ticket.
2. In your message, insert the following:

["/eTicket/thinks/this/is/the/link", "/this/is/what/shows/in/the/message"]

3. Submit your response and you'll see the link text as `"/this/is/what/shows/in/the/message"` with a URL of the eTicket root_url followed by `"/eTicket/thinks/this/is/the/link",`.

For example, the root_url could be "http://www.domain.com/support/" and the link created would be exactly:

http://www.domain.com/support/"/eTicket/thinks/this/is/the/link",

Yes, all quotes and other characters appear (including that comma at the end). This is happens ever-single-time you use brackets around text. This is a big problem for us since we provide a LOT of command line support and brackets are sometimes needed for CLI syntax purposes.

It's almost as if there's some BBcode support but it does not function correctly. :)

I've also tried to escape the characters with backslashes, but it just adds the backslash to the URL or displayed text (basically wherever the backslash is placed).

Let me know if you need additional info.

Incorrect Rep Timestamp...

2008-11-12T13:19:06Z

Bug ID:	42
Summary:	Incorrect Rep Timestamp...
Product/Component/Version:	eTicket - Community/1.7.3
Status:	Confirmed
Severity:	Minor

The timestamp on representative replies to customers is not being adjusted.

Right now, we had a customer submit a ticket at 14:40 MST (GMT -0700). The timestamp for the response from the customer is correct, however, our reply to the customer shows a timestamp of 07:21 MST.

I'm not sure why the time stamps are off, but I'm trying to find out what's causing this because at the current time, the responses are being provided before the questions (according to the timestamp that is).

Invalid HTML code in /themes/eticket/theme.php

2008-11-11T03:31:10Z

Bug ID:	35
Summary:	Invalid HTML code in /themes/eticket/theme.php
Product/Component/Version:	eTicket - Community/1.7.2
Status:	Closed
Severity:	Minor

On line 10 there is a missing quote:

<META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=<?php echo $db_settings['charset']; ?>>

Correct line:
<meta http-equiv="Content-Type" content="text/html; charset=<?php echo $db_settings['charset']; ?>">

Some browsers may not be able to correct this type of malformed HTML code, so these browsers may use the default charset, which is ISO-8859-1 often.

So the submitted data via the form will be also broken.

Predefined Responses MySQL Update...

2008-11-08T05:40:33Z

Bug ID:	41
Summary:	Predefined Responses MySQL Update...
Product/Component/Version:	eTicket - Community/1.7.3
Status:	Closed
Severity:	Moderate

When updating from 1.5.9 to 1.7.3, everything went smooth with the DB update. However, the predefined responses did not get updated so I lost them in the interface.

Upon checking with phpMyAdmin, I found that the predefined responses were in the DB, but the group assignment was "NULL" instead of "predef_answers" like it should be.

Using phpMyAdmin, I was able to update all of my existing predefined responses and get it so they could be used in the GUI again, but I feel that this should have been done as part of the DB update.

Valid Email Address being interpreted as invalid

2008-10-30T12:34:26Z

Bug ID:	40
Summary:	Valid Email Address being interpreted as invalid
Product/Component/Version:	eTicket - Community/1.7.3
Status:	Unconfirmed
Severity:	Trivial

Valid email address: cdanny_@hotmail.com is being marked as invalid when creating a ticket.

Error in function mp3_player (in file class.ticket.php)

2008-10-13T10:11:59Z

Bug ID:	30
Summary:	Error in function mp3_player (in file class.ticket.php)
Product/Component/Version:	eTicket - Community/1.7.2
Status:	Assigned
Severity:	Minor

There is an error in the mp3_player function in the file class.ticket.php

%file should be used in place of %fileurl

The following lines should read like:

Line 794 - data="%flashfile?&song_url=%attachurl?file=%file"
Line 797 - value="%flashfile?&song_url=%attachurl?file=%file"

instead of

Line 794 - data="%flashfile?&song_url=%attachurl?file=%fileurl"
Line 797 - value="%flashfile?&song_url=%attachurl?file=%fileurl"

SQL Injection possible in admin_mail.php

2008-09-30T11:37:20Z

Bug ID:	33
Summary:	SQL Injection possible in admin_mail.php
Product/Component/Version:	eTicket - Community/1.7.2
Status:	Closed
Severity:	Moderate

In admin_mail.php line 40, a SQL Injection could be performed. It may not be critical as it is in admin section but it also prevents writing texts in languages (such as french) that uses single quotes.

if (isset($_POST[$key])) $sqls[]="UPDATE ".$db_table['config']." SET ".$key." = '".$_POST[$key]."';";

Incoming HTML emails incorrectly processed

2008-08-16T19:15:58Z

Bug ID:	29
Summary:	Incoming HTML emails incorrectly processed
Product/Component/Version:	eTicket - Community/1.7.2
Status:	Assigned
Severity:	Minor

HTML emails received from Microsoft Outlook are displayed with "charset="US-ASCII" as their first line, followed by multiple blank lines and finally the text of the message.

I'm using an email forward with the new pipe.php. The old version Perl version didn't have this issue.

Thanks, Mike

Content encoding of incoming e-mails is ignored

2008-07-31T16:15:55Z

Bug ID:	28
Summary:	Content encoding of incoming e-mails is ignored
Product/Component/Version:	eTicket - Community/1.7.2
Status:	Closed
Severity:	Critical

Content encoding of incoming e-mails is ignored by pipe.php in 1.7.x versions.
automail.pl handled message encoding properly in 1.5.7 version.

Keep in mind that text in headers can be encoded using in place encoding like this:

Subject: =?windows-1251?B?yu7k6PDu4urg?=

Message body encoding is specified like this:

Content-Type: text/plain;
format=flowed;
charset="windows-1251";
reply-type=original

Encoding of incoming e-mails is ignored

2008-07-31T16:14:57Z

Bug ID:	27
Summary:	Encoding of incoming e-mails is ignored
Product/Component/Version:	eTicket - Community/1.7.2
Status:	Unconfirmed
Severity:	Critical

Accepted File Types under Preferences seem to be limited to 3 characters

2008-07-27T22:46:23Z

Bug ID:	21
Summary:	Accepted File Types under Preferences seem to be limited to 3 characters
Product/Component/Version:	eTicket - Community/1.7.2
Status:	Closed
Severity:	Trivial

.html is a common file extension and cannot be created directly

root_url for form action missing in open_form.php

2008-07-04T00:09:16Z

Bug ID:	20
Summary:	root_url for form action missing in open_form.php
Product/Component/Version:	eTicket - Community/1.7.1
Status:	Closed
Severity:	Minor

root_url is missing in /inc/open_form.php

Line 94:
[code]$form_action = '/open.php';[/code]

should be:
[code]$form_action = $root_url . '/open.php';[/code]

Ticket with German "Umlaute" doesn't arrive in full

2008-07-03T17:43:11Z

Bug ID:	14
Summary:	Ticket with German "Umlaute" doesn't arrive in full
Product/Component/Version:	eTicket - Community/1.7.0
Status:	Closed
Severity:	Critical

When writing a text like "Dies ist ein Test für die Version 1.7.0" eTicket only saves "Dies ist ein Test f" into the database. The rest of the text is lost.

eTicket graphic with transparent bg

2008-07-03T17:10:45Z

Bug ID:	19
Summary:	eTicket graphic with transparent bg
Product/Component/Version:	eTicket - Community/1.7.0
Status:	Closed
Severity:	Trivial

Please include the graphic of eTicket as pmg ore gif with transparent background in the next version. Not only we use different backgroundcolours then the 'basic' installation and white bg does not look very nice.

We know that we can disable the graphic, but we think ist would be better for the project to display ist.

webform - more attachments not functionally

2008-07-03T17:10:39Z

Bug ID:	18
Summary:	webform - more attachments not functionally
Product/Component/Version:	eTicket - Community/1.7.0
Status:	Closed
Severity:	Moderate

The webform is not functionally if a customer wants to attach more than one file. A click on 'ad another file' as soon as a first file is added does not generate a possibility to add another attachment.

!! This bug is only in the form for unregistered customer, the startsite of eTicket. All other forms are doing fine with the attachments-fields.

Problems with attachments / german Umlaute

2008-07-02T21:03:25Z

Bug ID:	16
Summary:	Problems with attachments / german Umlaute
Product/Component/Version:	eTicket - Community/1.7.0
Status:	Closed
Severity:	Moderate

Just installed 1.7.0 today.

Sent attachments via eMail to the ticketsystem were lost.

we fixed it with a string out of the 'old' automail.php:

[code]
$file = fopen($dest, 'w+');
fputs($file, $part);
fclose($file);
[/code]

The next problem we found are german 'Umlaute lkike ä, ö, ü.

Within the emailtext the get destroyed, we cound not find any fix.

charset for outgoing email not "UTF-8"

2008-06-29T21:30:18Z

Bug ID:	15
Summary:	charset for outgoing email not "UTF-8"
Product/Component/Version:	eTicket - Community/1.7.0
Status:	Closed
Severity:	Moderate

Email sent to customers have the content type 'text/plain; charset="iso-8859-1"'
Should be UTF-8

This is a problem when using languages with special characters.

SQL Injection bug

2008-06-20T17:38:34Z

Bug ID:	9
Summary:	SQL Injection bug
Product/Component/Version:	eTicket - Community/1.5.7
Status:	Closed
Severity:	Moderate

A SQL Injection vulnerability has been discovered in eTicket's ticket submission pages.

A detailed advisory describing the issue can be found at http://www.digitrustgroup.com/advisories/web-application-security-eticket2.html

Please notify us when a code fix is issued so that we may publicly publish this advisory. Also, please reference our original advisory where appropriate.

People are able to download settings.pl

2008-06-13T06:30:49Z

Bug ID:	8
Summary:	People are able to download settings.pl
Product/Component/Version:	eTicket - Community/1.5.7
Status:	Closed
Severity:	Critical

People are allowed to download settings.pl and automail.pl

Last X Answered Tickets

2008-06-12T21:37:04Z

Bug ID:	5
Summary:	Last X Answered Tickets
Product/Component/Version:	eTicket - Community/1.5.7
Status:	Closed
Severity:	Minor

I just wanted to bring this to your attention in case it has not been done/fixed already.

When the option to view the last X number of answered tickets is enabled, the number of tickets that shows there is correct. I'll use five for simplicities sake. If the option is set to five, then five tickets show up. However, the five tickets that show up are not actually the "last five answered" tickets. It appears to be more of the last five random tickets. I cannot find a patter.

For example, here are the last five tickets and dates when viewing the "View Answered" page:

212156 06/10/2008
581336 06/10/2008
812701 06/10/2008
850017 06/10/2008
660475 06/10/2008

Here are the last five tickets when viewing the open tickets panel under the "Last 5 Answered Tickets:"

866961 06/09/2008
241052 06/04/2008
913346 06/06/2008
767080 06/04/2008
327274 06/05/2008

As you can see, those are not the same tickets. Any idea why?

Thanks!

Step3 SQL Error

2008-06-12T21:34:03Z

Bug ID:	6
Summary:	Step3 SQL Error
Product/Component/Version:	eTicket - Community/1.5.7
Status:	Closed
Severity:	Moderate

While doing step3, the sql inserts fail with some error "the value of ID is out of range".
The error is in step3.php:
foreach ($value as $key => $val) {
if (empty($db_settings[$group])) {
$queries[]="INSERT INTO `".$db_table_prefix."settings` VALUES ('','$group','$key','$val')";
}
}
}
elseif (empty($db_settings[$key])) {
$queries[]="INSERT INTO `".$db_table_prefix."settings` VALUES ('','','$key','$value')";
}

Instead of VALUES ('','$group','$key','$val'), we need to change the first '' (the ID) to NULL, in both insert queries.
At least it doesn't work on MySQL 5.0.19 which is in my server. I think that in MySQL 4, it won't happen.

Bye!