Recent changes to bugs

Time Zone doesn't work

Kuhazor — Wed, 05 Sep 2007 05:40:49 -0000

We are in US central time zone and we have to set the timezone to Hawaii to get the time right. Server time is not set to UTC, but to US central time.

Reports page crashes

Kuhazor — Wed, 05 Sep 2007 05:39:03 -0000

Site Error

An error was encountered while publishing this resource.

Error Type: TypeError
Error Value: unsupported operand type(s) for +: 'int' and 'str'

Troubleshooting Suggestions

* The URL may be incorrect.
* The parameters passed to this resource may be incorrect.
* A resource that this resource relies on may be encountering an error.

For more detailed information about the error, please refer to the error log.

If the error persists please contact the site maintainer. Thank you for your patience.

listTickets.zsql produces invalid SQL for MySQL

Basil Hussain — Tue, 17 Apr 2007 11:04:58 -0000

I downloaded and tried to install the latest 2.1.1 release from SVN. It would fail to install completely, producing an error message when adding the MailManager product instance into Zope. The error it failed with was:

Traceback (innermost last):
Module ZPublisher.Publish, line 115, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 41, in call_object
Module Products.MailManager.MailManager, line 279, in manage_addMailManager
Module OFS.ObjectManager, line 333, in _setObject
Module zope.event, line 23, in notify
Module zope.app.event.dispatching, line 66, in dispatch
Module zope.component, line 181, in subscribers
Module zope.component.site, line 89, in subscribers
Module zope.interface.adapter, line 481, in subscribers
Module zope.app.event.objectevent, line 192, in objectEventNotify
Module zope.component, line 181, in subscribers
Module zope.component.site, line 89, in subscribers
Module zope.interface.adapter, line 481, in subscribers
Module OFS.subscribers, line 114, in dispatchObjectMovedEvent
Module OFS.subscribers, line 137, in callManageAfterAdd
Module Products.MailManager.MailManager, line 489, in manage_afterAdd
Module Products.MailManager.migrations, line 134, in migrate
Module Products.MailManager.migrations.v2_1, line 530, in migrate_v2_1_15_v2_1_16
Module Products.MailManager.sql, line 161, in __call__
Module Shared.DC.ZRDB.DA, line 454, in __call__
- <FSZSQLWrapper at /mailmanager/sql/listTickets>
Module Products.ZMySQLDA.db, line 306, in query
ProgrammingError: (1064, "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 'OFFSET 0' at line 49")

I tracked it down to the fact that when the listTickets SQL method is called with the 'sqv_nolimit' parameter set to true (which the migrate_v2_1_15_v2_1_16 method does), it was indeed producing an invalid query. The query it was attempting to run was this (as logged by MySQL server):

SELECT mm_ticket.*, state AS full_state
FROM mm_ticket
INNER JOIN mm_ticket_index ON mm_ticket.id = mm_ticket_index.id
OFFSET 0

Unlike PostgreSQL, in MySQL, an OFFSET clause cannot be used without an accompanying LIMIT clause (in effect, OFFSET is merely an argument to LIMIT).

The solution I found was to remove the "OFFSET 0" part entirely. In MySQL, OFFSET is optional, and specifying an offset of zero is the same as not specifying one at all. I only made this change for MySQL, as I believe OFFSET to always be required in Postgres.

The relevant section of listTickets.zsql now reads:

<dtml-if sqv_offset>
<dtml-if expr="sql_database == 'postgres'">
OFFSET <dtml-var sqv_offset>
<dtml-elif expr="sql_database == 'oracle'">

<dtml-elif expr="sql_database == 'mysql'">
OFFSET <dtml-var sqv_offset>
</dtml-if>
<dtml-else>
<dtml-if expr="sql_database == 'postgres'">
OFFSET 0
<dtml-elif expr="sql_database == 'oracle'">

<dtml-elif expr="sql_database == 'mysql'">

</dtml-if>
</dtml-if>

MySQL cron database locks not being released

Basil Hussain — Tue, 10 Apr 2007 14:36:57 -0000

When trying to investigate a problem with MM not processing mail when using the MMCron.py script, I came across the following bug. My problem was that the 'get_mail' task was being process the first time after Zope initialisation, but would error every time afterwards with "Failure to get lock for get_mail" in the logs.

I tracked it down to a problem caused by the ZSQL method used to release the MySQL database locks (when processing the tasks called by 'process_tasks') being broken.

If we look at the MySQL-specific statement used in getCronLock.zsql, we can see that it does the following:

SELECT GET_LOCK('cron_<dtml-var sqv_lock_name>', 5) AS lockval

However, if we look at the MySQL statement used in releaseCronLock.zsql, it does this:

SELECT RELEASE_LOCK('<dtml-var sqv_lock_name>') AS lockval

Spot the mistake? The lock string name on the release call isn't the same! It's missing the 'cron_' prefix. This means that ANY locks set in MySQL would never actually be released, no matter what!

It should obviously be corrected to:

SELECT RELEASE_LOCK('cron_<dtml-var sqv_lock_name>') AS lockval

MySQL field mm_message.raw_headers should be TEXT not BLOB

Thimo Kraemer — Tue, 20 Feb 2007 10:57:34 -0000

Shouldn't the MySQL field mm_message.raw_headers be TEXT instead of LONGBLOB? When viewing the headers of a ticket you currently get an array type.

Other ZMySQLDA instances are affected by unicode patch

Thimo Kraemer — Fri, 16 Feb 2007 12:21:04 -0000

When combining unicode and non-unicode MySQL connections, each instance is affected by the other one. Depending on which instance used last.

This is due to the fact that some items of the conversions list are references instead of independent objects (e.g. conv[FIELD_TYPE.BLOB]).

Furthermore it is possible to patch just one file of the ZMySQLDA package to get unicode support instead of four files.

To get this working, you have to modify only two functions of db.py
Now you can turn on unicode support by adding the string "use_unicode" to the end(!) of the connection string.

def _parse_connection_string(self, connection):
kwargs = {'conv': self.conv.copy()}
items = split(connection)
if not items: return kwargs
if items[-1] == 'use_unicode':
self.use_unicode = True
del items[-1]
# Update the converters on the unicode object
def u(s):
return s.decode('UTF8')
kwargs['conv'][FIELD_TYPE.STRING] = u
kwargs['conv'][FIELD_TYPE.VAR_STRING] = u
kwargs['conv'][FIELD_TYPE.BLOB] = self.conv[FIELD_TYPE.BLOB][:]
kwargs['conv'][FIELD_TYPE.BLOB].insert(-1, (None, u))
else:
self.use_unicode = False
# Reset these elements - by default they should not be present
if self.conv.has_key(FIELD_TYPE.STRING):
kwargs['conv'][FIELD_TYPE.STRING] = self.conv[FIELD_TYPE.STRING]
elif kwargs['conv'].has_key(FIELD_TYPE.STRING):
del kwargs['conv'][FIELD_TYPE.STRING]
if self.conv.has_key(FIELD_TYPE.VAR_STRING):
kwargs['conv'][FIELD_TYPE.VAR_STRING] = self.conv[FIELD_TYPE.VAR_STRING]
elif kwargs['conv'].has_key(FIELD_TYPE.VAR_STRING):
del kwargs['conv'][FIELD_TYPE.VAR_STRING]
if self.conv.has_key(FIELD_TYPE.BLOB):
kwargs['conv'][FIELD_TYPE.BLOB] = self.conv[FIELD_TYPE.BLOB]
elif kwargs['conv'].has_key(FIELD_TYPE.BLOB):
del kwargs['conv'][FIELD_TYPE.BLOB]
db_host, items = items[0], items[1:]
if '@' in db_host:
db, host = split(db_host,'@',1)
kwargs['db'] = db
if ':' in host:
host, port = split(host,':',1)
kwargs['port'] = int(port)
kwargs['host'] = host
else:
kwargs['db'] = db_host
if kwargs['db'][0] in ('+', '-'):
self._try_transactions = kwargs['db'][0]
kwargs['db'] = kwargs['db'][1:]
else:
self._try_transactions = None
if not items: return kwargs
kwargs['user'], items = items[0], items[1:]
if not items: return kwargs
kwargs['passwd'], items = items[0], items[1:]
if not items: return kwargs
kwargs['unix_socket'], items = items[0], items[1:]
return kwargs

def string_literal(self, s):
if self.use_unicode and type(s) == unicode:
s = s.encode('UTF8')
return self.db.string_literal(s)

SEARCH - no 2007 Selection

Dick Calhoun - Imm — Mon, 08 Jan 2007 16:38:48 -0000

In SEARCH Options there is NO year 2007 on the list? This exists in version 2.0.10 also.

Performance drops dramatically as the database grows

Geir Bćkholt — Fri, 05 Jan 2007 08:57:03 -0000

As the number of mails in the database grows, the performance when writing (sending replies, adding notes) drops dramatically. it can currently take 30 seconds to send a reply on our deployment.

We initially believed it to be related to the sending of mail, but the problem persistst even after replacing the mailhost with maildrophost. The problem also appears when adding notes.

Since this happens unrelated to mail-sending and even when only adding notes, everything points towards either a table without proper indexes or a miswritten SQL query.

Search dates not available for 2007

Kevin Campbell — Tue, 02 Jan 2007 14:50:00 -0000

There is no option to search for tickets from 2007.

Looking at the code, it appears that the date range is hardcoded. This needs replaced.

Page list never displays '6'

Mon, 13 Nov 2006 10:37:10 -0000

The page listing at the top left of the issue list page
does not display the 6th page link. ever.

There is a 6th page, and when I delete everything on
page 7 it takes me to it, thus this page and page 5
both have "1 2 3 4 5" at the top left, no 6.