Incorrect initialization of new custom fields in existing tickets.

[roger.oberholtzer@…]

When adding a custom field, it is possible to set what the default value should be when a new ticket is created, For existing tickets that do not yet have this value, the field seems to default to the first value (I have a 'select'-type variable). I would have expected it to be set to the same default value as for a new ticket. Is this expected behavior? I really would like all existing tickets to have the default value for this field.

It has been confirmed that this same behavior exists in the current trunk release.

[Ryan J Ollos]

Discussed in ​gmessage:trac-users:PzCJd7DxXl8/FVFommcpBwAJ. We should try to fix the issue for milestone:1.2.

[Ryan J Ollos]

Proposed changes in log:rjollos.git:t12252_ticket_custom_default. I'll add additional tests before committing.

The population of default ticket custom field values would probably benefit from a redesign. Even after the proposed changes, a value won't be stored for a ticket created before a custom field was added, until there is an update to that ticket. The behavior is probably odd to the user - a custom query that filters for a non-empty custom field only returning tickets that have been updated since the custom field was added.

[Ryan J Ollos]

Added a test in [12e4f578/rjollos.git]. Also modified TicketSystem.reset_ticket_fields to clear the cached property custom_fields, which was an issue discovered after writing the test.

[Ryan J Ollos]

Replying to Ryan J Ollos:

Also modified TicketSystem.reset_ticket_fields to clear the cached property custom_fields, which was an issue discovered after writing the test.

It looks like this isn't needed outside of test execution since the environment is recreated when the trac.ini file contents change. Changing the [ticket-custom] definition will therefore result in recomputing the cached ticket fields and custom fields.

In the test case I'll just explicitly del TicketSystem(self.env).custom_fields.