TicketQueryMacro is inconsistent in its case-sensitivity only for the "component" field.

[bellaire@…]

When specifying a TicketQueryMacro's fields, for purposes of the result, it is case-insensitive with respect to how "component" is specified. See the following examples:

[[TicketQuery(component=general,status!=closed,format=table)]]
[[TicketQuery(Component=general,status!=closed,format=table)]]

Both tables will contain exactly the same tickets. However, the links constructed for the column headers in format=table pass through the casing of the original query, and Custom Query will not recognize the upper-cased version of the field. This results in unexpected behavior; for TicketQuery against component, if the casing is not correct, the query itself will work but the corresponding Custom Query (when clicking on headers) will not.

This appears to only happen for the component field, all other fields seem to require proper casing (all lowercase). Using incorrect case with other build-in fields results in an error rendering the macro. Additionally, the specific mix of upper and lowercase in "component" does not matter, e.g. component, COMPONENT, ComPOnENt, all produce the same behavior.

The behavior should probably simply be fixed so that all fields are case-sensitive, and the incorrect caps on the component field name can be caught sooner (during a preview, for instance).

[Remy Blank]

Weird.

[Christian Boos]

Can't reproduce.

Well, I don't really see how this could have happened, as the tickets are fetched first, before the output format is even considered.

What could have been happened is that all the non-closed tickets had component=general, and Component=general being not a valid criterion it got ignored and all the non-closed tickets were returned.