Yesterday I worked on streamlining our ticket workflow in Trac. While I was in the test project anyway, I decided to address an issue that had bugged me since I first set up Trac. I originally set up two custom ticket fields related to case IDs in our CRM system:

crmnum = text
crmnum.label = Case #
crmnum.format = plain
crmnum.order = 1
crmlink = text
crmlink.label = Case Link
crmlink.format = wiki
crmlink.order = 3

The idea was that we could have the “crmnum” field to just hold the ID, which we could act on programmatically. The “crmlink” field would be a copy/paste link of the ticket’s URL, which would allow someone looking at the ticket to click through to the CRM case easily.

The problem with this is that the link is long and ugly and completely throws off the tidiness of the ticket summary.

So, having recently figured out how to write a custom wiki macro, I decided to create one for links to our CRM system also. The idea would be that the “crmlink” field would go away and the “crmnum” field could be updated to use the wiki Macro to generate the link automatically.

I nuked the “crmlink” field and changed “crmnum” from “type = plain” to “type = wiki“. I wrote my custom CRM macro, testing it in the wiki itself until I had it behaving. I then created a new ticket, entered [[CRM(123)]] in the crmnum field, and clicked “Preview”. Instead of seeing the link it should have returned, instead I got [[CRM(...)]]. I did some testing and proved to myself that some wiki processing was taking place (ticket:1 expanded correctly) and that no macro expanded in that field, including built-in macros.

Then on a hunch, I changed crmnum to “type = textarea” instead of “type = text“. Sure enough, macros work properly in textarea fields but not text fields. In a way this makes sense since almost all built-in macros return multiple lines of text. The documentation for custom ticket fields doesn’t mention that wiki processing behavior differs between these field types. Unfortunately the textarea fields can’t easily be tricked into looking like a simple text field. They come with an editing bar, and they are assigned the same class as the description field, so you can’t easily use CSS tricks on it.

I was unsure if this was a bug or intentional, but I managed to find the original Trac ticket for adding wiki processing to custom fields, and it’s clear that it was intentional to make the wiki-processing behavior of the two field types differ. Specifically, text fields are processed with format_to_oneliner() and textareas are processed with format_to_html() (this can be seen in the change to web_ui.py associated with new feature.

After figuring out that the text/textarea parsing differences were done intentionally, I lost interest in patching the code itself. Instead I looked into using InterWiki links instead of macros, which are processed in text fields.

I created trac ticket 10352 about this issue, hopefully it gets addressed one way or another.