Changes between Version 1 and Version 2 of TracTicketsCustomFields
- Timestamp:
- Jan 4, 2006, 5:52:42 PM (19 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
TracTicketsCustomFields
v1 v2 1 1 = Custom Ticket Fields = 2 Trac support adding custom, user-defined, fields to the ticket module. Using custom fields, you can add typed, site-specific,properties to tickets.2 Trac supports adding custom, user-defined fields to the ticket module. Using custom fields, you can add typed, site-specific properties to tickets. 3 3 4 '''Note: In Trac 0.8, this feature is still experimental.''' 5 6 == Configuriation == 7 Configuring custom ticket fields is done in the TracIni config file. 8 9 All field definitions should be under a section named [ticket-custom] in the ini-file. 4 == Configuration == 5 Configuring custom ticket fields is done in the [wiki:TracIni trac.ini] file. All field definitions should be under a section named `[ticket-custom]`. 10 6 11 7 The syntax of each field definition is: … … 15 11 ... 16 12 }}} 17 Looking at the example below should helpexplain the syntax.13 The example below should help to explain the syntax. 18 14 19 15 === Available Field Types and Options === … … 38 34 * label: Descriptive label. 39 35 * value: Default text. 40 * width: Width in columns.41 * height: Height in lines.36 * cols: Width in columns. 37 * rows: Height in lines. 42 38 * order: Sort order placement. 43 39 … … 45 41 {{{ 46 42 [ticket-custom] 43 47 44 test_one = text 48 45 test_one.label = Just a text box … … 69 66 test_six.label = This is a large textarea 70 67 test_six.value = Default text 71 test_six. width= 6072 test_six. height= 3068 test_six.cols = 60 69 test_six.rows = 30 73 70 }}} 71 72 ''Note: To make an entering an option for a `select` type field optional, specify a leading `|` in the `fieldname.options` option.'' 73 74 === Reports Involving Custom Fields === 75 76 The SQL required for TracReports to include custom ticket fields is relatively hard to get right. You need a `JOIN` with the `ticket_custom` field for every custom field that should be involved. 77 78 The following example includes a custom ticket field named `progress` in the report: 79 {{{ 80 #!sql 81 SELECT p.value AS __color__, 82 id AS ticket, summary, component, version, milestone, severity, 83 (CASE status WHEN 'assigned' THEN owner||' *' ELSE owner END) AS owner, 84 time AS created, 85 changetime AS _changetime, description AS _description, 86 reporter AS _reporter, 87 (CASE WHEN c.value = '0' THEN 'None' ELSE c.value END) AS progress 88 FROM ticket t 89 LEFT OUTER JOIN ticket_custom c ON (t.id = c.ticket AND c.name = 'progress') 90 JOIN enum p ON p.name = t.priority AND p.type='priority' 91 WHERE status IN ('new', 'assigned', 'reopened') 92 ORDER BY p.value, milestone, severity, time 93 }}} 94 95 Note in particular the `LEFT OUTER JOIN` statement here. 74 96 75 97 ----