Allow changing group of tickets on drag

[Danny Sauer]

It would be convenient if I there were support for the ability to change the queue on drag-and-drop as well. If I use a relatively simple statement for the field inserted as __group__ in my SQL like the below, it'd be nice if I could drag from one r.value group to another and have the value updated. As it sits, the sequence seems to be tracked properly between the grouped queues, but the grouped field is not updated when I drag from one queue to another.

SELECT s.value AS __color__,
       r.value AS __group__,
       p.value AS sequence,
       t.id AS ticket,
       summary, 
       t.type AS type, t.severity, t.owner
FROM ticket t
LEFT JOIN enum s ON s.name = t.severity AND s.type = 'severity'
LEFT OUTER JOIN ticket_custom p ON p.ticket = t.id and p.name = 'sequence'
LEFT OUTER JOIN ticket_custom r ON r.ticket = t.id and r.name = 'rank'
WHERE t.status <> 'closed'
ORDER BY CAST((CASE p.value
                WHEN '' THEN '0'
                ELSE COALESCE(p.value,'0') END) AS INTEGER) ASC,
         t.changetime DESC

I suppose one would have to be able to tell if the field referenced is a valid field/customfield value, which makes this a tad harder. But I'd like to log it as a request none the less. :)

[Rob Guttman]

Happy to see you using this plugin and pushing it to its limits! Or perhaps beyond..

Hmm, yeah, the plugin wasn't designed to support multiple queues in a single report. As you may know, there could be multiple fields that determine the actual queue so figuring that out automatically and reliably would be tricky. I suppose it's possible to provide some manual hints in trac.ini but that would likely complicate the plugin.

I'll need to think about this some - but likely not a priority. As a workaround, you could try using the GridModify plugin to manually update the queue field(s).

[anonymous]

My workaround was to create a duplicate report using the batchmodify plugin, as gridmodify didn't work well for me before. But it seems to be ok now, so who knows what was going on before. That works well now.

In any event, not knowing much about what data the plugin gets, I wonder if the relatively simple case like this could use something like an additional AS __group_fieldname__ entry in the select statement to indicate the field name being grouped upon. But I don't know if those are stripped out before the plugin could get access to the data. A similar structure could potentially work with the TracQuery syntax; just add another arbitrary parameter name?

I just need to read more about the trac plugin architecture. But I already get Perl and ksh syntax jumbled when I'm working one or the other - adding Python probably won't end well. :)