Edgewall Software
Modify

Opened 7 years ago

Closed 7 years ago

Last modified 4 years ago

#10951 closed defect (invalid)

[PATCH] Custom field order is not preserved

Reported by: chris.nelson.1022@… Owned by:
Priority: normal Milestone:
Component: ticket system Version: 0.11.6
Severity: normal Keywords: custom field order needinfo
Cc: Branch:
Release Notes:
API Changes:

Description (last modified by Ryan J Ollos <ryan.j.ollos@…>)

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:

ReporterOwner
PriorityMilestone
Custom 6Custom 7
Custom 8Custom 9
CCKeywords
Custom 0Custom 1
Custom 2Custom 3
Custom 4Custom 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.

Attachments (1)

custom_order.patch (1.4 KB ) - added by Chris.Nelson@… 7 years ago.
Patch to enforce custom field order

Download all attachments as: .zip

Change History (8)

by Chris.Nelson@…, 7 years ago

Attachment: custom_order.patch added

Patch to enforce custom field order

comment:1 by Chris.Nelson@…, 7 years ago

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

  • trac/ticket/templates/ticket.html

    a b  
    159159              <td headers="h_owner">${ticket.owner and authorinfo(ticket.owner)
    160160              </td>
    161161            </tr>
     162         <span py:with="fieldorder=[f['name'] for f in fields]">
     163             ${pprint('fieldorder:%s' % fieldorder)}
     164          </span>
    162165            <tr py:for="row in group(fields, 2, lambda f: f.type != 'textarea')
    163166              py:with="fullrow = len(row) == 1">
    164167              <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.

comment:2 by anonymous, 7 years ago

Summary: [PATHC] Custom field order is not preserved[PATCH] Custom field order is not preserved

comment:3 by Ryan J Ollos <ryan.j.ollos@…>, 7 years ago

Description: modified (diff)

comment:4 by Christian Boos, 7 years ago

Keywords: needinfo added

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).

in reply to:  4 comment:5 by Chris.Nelson@…, 7 years ago

Resolution: invalid
Status: newclosed

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.

comment:6 by Chris.Nelson@…, 7 years ago

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:

56
89
100
12
34
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.

comment:7 by Ryan J Ollos, 4 years ago

Reporter: changed from Chris.Nelson@… to chris.nelson.1022@…

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The ticket will remain with no owner.
The resolution will be deleted. Next status will be 'reopened'.
to as closed The owner will be changed from (none) to the specified user.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.