[PATCH] Custom field order is not preserved

[chris.nelson.1022@…]

It appears that _prepare_fields() in ticket/web_ui.py is supposed to order the fields for the ticket property box:

• Most standard fields
• Custom fields in the order specified by the user
• Keywords

However, what I see is like:

Reporter	Owner
Priority	Milestone
Custom 6	Custom 7
Custom 8	Custom 9
CC	Keywords
Custom 0	Custom 1
Custom 2	Custom 3
Custom 4	Custom 5

I've displayed the names, in order, from fields in templates/ticket.html and the fields are in the wrong order as the ticket is displayed.

This may be a complex interaction of many plugins. Or one plugin's ticket handling reordering fields. (I have ~30 plugins installed.) While there may be a bug in a plugin that should not reorder fields, Trac can enforce its intended order with the attached patch.

[Chris.Nelson@…]

Patch to enforce custom field order

[Chris.Nelson@…]

By the way, the change I made to display field order in the ticket template is:

trac/ticket/templates/ticket.html

@@ -159 +159 @@
               <td headers="h_owner">${ticket.owner and authorinfo(ticket.owner)
               </td>
             </tr>
+         <span py:with="fieldorder=[f['name'] for f in fields]">
+             ${pprint('fieldorder:%s' % fieldorder)}
+          </span>
             <tr py:for="row in group(fields, 2, lambda f: f.type != 'textarea')
               py:with="fullrow = len(row) == 1">
               <py:for each="idx, field in enumerate(row)">

I wish I could figure out how to write to trac.log from a template but this is the best I could do.

[Christian Boos]

If I'm not mistaken, you're saying this is not a problem with Trac alone, but that's a side-effect of some plugin?

If really so, no, it's not Trac's job to come after and clean-up the mess… The plugin should be fixed (and what if the plugin did want to change the order in some ways - I bet there are plugins doing just that).

[Chris.Nelson@…]

Replying to cboos:

If I'm not mistaken, you're saying this is not a problem with Trac alone, but that's a side-effect of some plugin?

Well, as I prepare to migrate from 0.11.6 to 1.0, I find that we have a local patch that tries to force keywords to the end of the list of standard fields. That core patch seems ill-advised and I'm not sure we'll keep it. It may also be badly implemented and the source of our problem. I haven't yet tested without it but I will.

If really so, no, it's not Trac's job to come after and clean-up the mess… The plugin should be fixed (and what if the plugin did want to change the order in some ways - I bet there are plugins doing just that).

I'm not sure I agree. For example, in 0.11.6, ticket change listeners are not invoked within a try so if one fails, others don't execute and that can be a problem. It would be more robust for Trac to catch those errors so one plugin doesn't compromise another. This seems in that vein.

OTOH, I'd favor a more general solution which allowed the administrator to specify the order of standard fields in much the same way they can specify the order of custom fields. That would make this patch obsolete.

All of that said, this is a false start at fixing a problem that may not exist.

[Chris.Nelson@…]

FWIW, with this patch and the earlier one I'd applied locally and forgotten about reverted, the standard/core and custom fields are not intermixed but I see custom fields ordered like:

5	6
8	9
10	0
1	2
3	4
7

5 and 6 are just locally-defined custom fields with select values and no plugin code behind them. 8 and 9 are from Timing and Estimation and there is code to hide 8 (Add Hours to Ticket) but it's disabled. I really have no explanation for this weird reordering.