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:<\/p>\n
\r\ncrmnum = text\r\ncrmnum.label = Case #\r\ncrmnum.format = plain\r\ncrmnum.order = 1\r\ncrmlink = text\r\ncrmlink.label = Case Link\r\ncrmlink.format = wiki\r\ncrmlink.order = 3\r\n<\/pre>\nThe idea was that we could have the “
crmnum<\/code>” field to just hold the ID, which we could act on programmatically. The “crmlink<\/code>” 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.<\/p>\nThe problem with this is that the link is long and ugly and completely throws off the tidiness of the ticket summary.<\/p>\n
So, having recently figured out how to write a custom wiki macro<\/a>, I decided to create one for links to our CRM system also. The idea would be that the “
crmlink<\/code>” field would go away and the “crmnum<\/code>” field could be updated to use the wiki Macro to generate the link automatically.<\/p>\nI nuked the “
crmlink<\/code>” field and changed “crmnum<\/code>” from “type = plain<\/code>” to “type = wiki<\/code>“. 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)]]<\/code> in the crmnum field, and clicked “Preview”. Instead of seeing the link it should have returned, instead I got[[CRM(...)]]<\/code>. 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.<\/p>\nThen on a hunch, I changed crmnum to “
type = textarea<\/code>” instead of “type = text<\/code>“. 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<\/a> 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.<\/p>\nI 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<\/a>, 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()<\/code> and textareas are processed withformat_to_html()<\/code> (this can be seen in the change to web_ui.py associated with new feature<\/a>.<\/p>\nAfter 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<\/a>, which are processed in text fields.<\/p>\n
I created trac ticket 10352<\/a> about this issue, hopefully it gets addressed one way or another.<\/p>\n","protected":false},"excerpt":{"rendered":"
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 … Continue reading