Edgewall Software

Ticket #1449 (new defect)

Opened 3 years ago

Last modified 3 months ago

Trac does not check for conflicts with custom fields, Action box disappears

Reported by: avalys@… Owned by: osimons
Priority: normal Milestone: 0.11.3
Component: ticket system Version: 0.9
Severity: normal Keywords: custom fields
Cc: ashearerw@…

Description

If I create a custom ticket field by editing trac.ini, Trac does not check to see if the name of my custom field conflicts with the name of one of the stock fields.

For instance, if I create a field named 'status', anytime I make a change to the ticket that results in the stock 'status' field being changed, trying to submit the change results in an SQLite index violation error ("columns ticket, time field are not unique").

I don't know if it would be better to automatically check for these conflicts, or just named all custom fields custom_something.

Attachments

Change History

Changed 3 years ago by ashearerw@…

  • version changed from 0.8.1 to 0.9

The behavior in Trac 0.9 has changed. The entire Action box now disappears if there's a custom field named 'status', making it impossible to accept or close tickets. New or upgrading users can run into this, and the cause isn't obvious, especially since this worked for the most part under 0.8. (Specifically, everything worked under 0.8 unless the user both changed the custom status field and selected a ticket action in one form submission, which would result in the 'not unique' error message. Doing the same thing in two steps worked perfectly.)

At least one other person on the Trac mailing list apart from me encountered this when we upgraded to 0.9. Renaming the custom field (and running an UPDATE statement on the database to convert the old data) fixed it. The need for more status values is probably common, and naming a custom field 'status' isn't explicitly disallowed by the current documentation, so I'd expect others could run into this too.

I'd submit a patch to either the code or documentation, but I don't know which route the Trac developers would prefer.

  1. Disallow all custom fields with the same names as built-in fields. If so, the TracTicketsCustomFields wiki page should be updated with that information and provide a list of the built-in fields to avoid. The Trac code could also be updated to check for conflicts and generate an error message.
  2. Instead, allow any custom field name, including 'status'. Since this almost worked in 0.8, it may be well be technically feasible. Trac would have to be changed to show the Action box even if there's a custom status field (matching 0.8's behavior), and to fix the "columns ticket, time field are not unique" message.

--Andrew Shearer

Changed 3 years ago by ashearerw@…

  • summary changed from Trac does not check for conflicts with custom fields to Trac does not check for conflicts with custom fields, Action box disappears

Changed 3 years ago by anonymous

  • cc ashearerw@… added

Changed 2 years ago by sid

#2979 has been marked as a duplicate.

Changed 19 months ago by cboos

  • keywords custom fields added
  • milestone set to 0.12

I'd favor solution 1. from comment:1.

Changed 16 months ago by cboos

#5494 was closed as duplicate. There, the problem was for group. While this is not a name of a regular ticket field, there's nonetheless a conflict with the group selector using in the TracQuery language. The full list is:

  • report, order, desc, group, groupdesc, col, row, format

Changed 16 months ago by cboos

  • owner changed from jonas to cboos
  • milestone changed from 0.12 to 0.11

Changed 3 months ago by osimons

  • owner changed from cboos to osimons

I'm +1 on the first suggestion as well, and we should make a reserved_field_names list that we check; skip the field if name is reserved + log the error.

Add/Change #1449 (Trac does not check for conflicts with custom fields, Action box disappears)

Author



Change Properties
<Author field>
Action
as new
as The resolution will be set. Next status will be 'closed'
to The owner will change from osimons. Next status will be 'new'
The owner will change from osimons to anonymous. Next status will be 'assigned'
 
Note: See TracTickets for help on using tickets.