Error: Macro TracJSGanttChart(milestone=Moe) failed estimatedhours

[stefan.voelkel@…]

Hi,

this is in debian squeeze, with Trac 0.12 and these plugins:

AutocompleteUsers-0.4.1-py2.6.egg
BatchModify-0.8.0_trac0.12-py2.6.egg
TestManager-1.4.4-py2.6.egg
timingandestimationplugin-1.1.1-py2.6.egg
TracGenericClass-1.0.4-py2.6.egg
TracGenericWorkflow-1.0.2-py2.6.egg
Trac_jsGantt-0.3-py2.6.egg
TracSubTicketsPlugin-0.1.0-py2.6.egg
TracTicketTemplate-0.7-py2.6.egg
TracXMLRPC-1.1.2-py2.6.egg

The generated SELECT throws an Syntax error:

  Error: near "'Moe'": syntax error

The Problem is a stray u with t.milestone:

SELECT t.id AS id,t.description AS description,t.owner AS owner,t.type AS type,t.status AS status,t.summary AS summary,t.milestone AS milestone,t.priority AS priority,t.time AS time,t.changetime AS changetime,priority.value AS priority_value,`parents`.value AS `parents`,`estimatedhours`.value AS `estimatedhours`,`totalhours`.value AS `totalhours`
FROM ticket AS t
  LEFT OUTER JOIN ticket_custom AS `parents` ON (id=`parents`.ticket AND `parents`.name='parents')
  LEFT OUTER JOIN ticket_custom AS `estimatedhours` ON (id=`estimatedhours`.ticket AND `estimatedhours`.name='estimatedhours')
  LEFT OUTER JOIN ticket_custom AS `totalhours` ON (id=`totalhours`.ticket AND `totalhours`.name='totalhours')
  LEFT OUTER JOIN enum AS priority ON (priority.type='priority' AND priority.name=priority)
WHERE ((COALESCE(t.milestone,'')=u'Moe'))
ORDER BY COALESCE(priority.value,'')='',CAST(priority.value AS integer),t.id

Changing the WHERE line to:

WHERE ((COALESCE(t.milestone,'')='Moe'))

fixes the syntax error (at least with sqlit3 tdb/rac.db)

Stefan

[pb903@…]

I have the same error and i've debugged you code: I've added:

 if self.fields['estimate']:
                    msTicket[self.fields['estimate']] = 0

inside of the _add_milestones(self, options) method under the:

 if self.fields['parent']:
                    msTicket[self.fields['parent']] = 0 line

now it works ...

[Ryan J Ollos]

The original issue reported here is likely no longer valid ... it looks like the queries have been rewritten. The issue in comment:1 is unlikely to be related, even though the same generic error results. I'll test with the estimate field set and unset and open another ticket with a patch if there is an issue.