Allow enums to be used in ticket custom value sets

[Colin Guthrie]

I am writing a plugin that just adds a custom ticket field. It is to hold a list of clients to which a ticket "belongs" but that is not really important.

The possible values for this could be quite long and using the .options value of the .ini file doesn't seem appropriate.

So I thought a sensible route would be to use the enum table to hold the values and write a simple extension to TracWebAdmin to add another editing page page based on AbstractEnumAdminPage type (I'm not sure if this is still part of Trac 0.11 with merged TracWebAdmin tho' :))

Anyway, this patch allows easy use of the enum table and easy ways to hook up custom fields to use that list. This would not really be of use to people unless they create a plugin to admin the actual list too but it's still a useful feature IMO and the patch itself is fairly unobtrusive, so hopefully you can accept it.

The changes just allow a .options value of "enum:name" where name is the name you give to your enum and this will load the values from the database rather than parsing a pipe-separated list.

The other change was for when an enum name is updated (name changed) and which then updates the ticket table to reflect said changes. I just added a check so that it can update the ticket_custom table instead.

Hope this is acceptable. Not adding my mail here as I don't want it spammed but I will check back for updates. Patches are against 0.10.4

[Colin Guthrie]

Hmmm, don't know why but the built in Trac viewer for diff file format doesn't like my patch and it's only showing the first file - seems like I've just found another bug :)

The raw format show it correctly: ​http://trac.edgewall.org/attachment/ticket/5641/custom_enum.diff?format=raw

[Colin Guthrie]

For reference I've uploaded a plugin that makes use of this new feature:

The exceptionally complex code for the plugin is here: ​http://www.trac-hacks.org/browser/clientsplugin/0.10/clients/client.py

The plugin itself can be found here: ​http://www.trac-hacks.org/wiki/ClientsPlugin

Obviously this is just an example (and a simple one at that) but it illustrates the point :D

[Christian Boos]

Replying to Colin Guthrie:

Hmmm, don't know why but the built in Trac viewer for diff file format doesn't like my patch and it's only showing the first file - seems like I've just found another bug :)

This has been fixed on trunk, though I'm not sure in which changeset exactly (probably r4067).

[Christian Boos]

Interesting idea, I'll keep note of the proposal and see how it can be handled in the new flexible property scheme (FieldRefactoring / GenericTrac).

But at this stage I'm not sure it will be implemented in the current form (enum:name value for the options), so it doesn't make sense to integrate in 0.10 (which is mostly "closed" for new features anyway).

[Colin Guthrie]

OK, thanks for the feedback :)

[Colin Guthrie]

OK, here is an updated patch that adds a new Interface/ExtensionPoint that means that plugins can provide a list of custom field values to custom fields. The change is quite simple and I think useful. It means plugins can do a lot more with field values. If possible I'd love to see this in 0.11… I'd say this can replace the previous patch as although it's not exactly the same, it's much more flexible.

[Noah Kantrowitz]

-1 on this being in core right now. Should be doable as a plugin.

[Colin Guthrie]

Yeah, I spoke to coderanger on irc and he explained how this could be done. I'll work on a plugin to do this instead. The general enum: concept is still quite a good one I reckon, to allow people to create custom fields and possible values easily but as cboos said that is one for GenericTrac