Changes between Initial Version and Version 1 of TracTicketsCustomFields


Ignore:
Timestamp:
Feb 14, 2025, 8:38:07 AM (10 months ago)
Author:
trac
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • TracTicketsCustomFields

    v1 v1  
     1= Custom Ticket Fields
     2
     3Trac supports adding custom, user-defined fields to the ticket module. With custom fields you can add typed, site-specific properties to tickets.
     4
     5== Configuration
     6
     7Configure custom ticket fields in the [TracIni#ticket-custom-section "[ticket-custom]"] section of trac.ini.
     8
     9The syntax of each field definition is:
     10{{{
     11 FIELD_NAME = TYPE
     12 (FIELD_NAME.OPTION = VALUE)
     13 ...
     14}}}
     15
     16The example below should help to explain the syntax.
     17
     18=== Field Names
     19
     20A field name can only contain lowercase letters a-z, uppercase letters A-Z or digits 0-9, and must not start with a leading digit.
     21
     22The following field names are reserved and can not be used for custom fields:
     23* cc
     24* changetime
     25* col
     26* comment
     27* component
     28* desc
     29* description
     30* format
     31* group
     32* groupdesc
     33* id
     34* keywords
     35* max
     36* milestone
     37* or
     38* order
     39* owner
     40* page
     41* priority
     42* report
     43* reporter
     44* resolution
     45* row
     46* severity
     47* status
     48* summary
     49* time
     50* type
     51* verbose
     52* version
     53
     54=== Available Field Types and Options
     55
     56 * '''text''': A simple (one line) text field.
     57   * label: Descriptive label.
     58   * value: Default value.
     59   * order: Sort order placement relative to other custom fields.
     60   * max_size: Maximum allowed size in characters (//Since 1.3.2//).
     61   * format: One of:
     62     * `plain` for plain text
     63     * `wiki` for [WikiFormatting wiki formatted] content
     64     * `reference` to treat the content as a queryable value
     65     * `list` to interpret the content as a list of queryable values, separated by whitespace
     66 * '''checkbox''': A boolean value check box.
     67   * label: Descriptive label.
     68   * value: Default value, 0 or 1.
     69   * order: Sort order placement.
     70 * '''select''': Drop-down select box. Uses a list of values.
     71   * label: Descriptive label.
     72   * options: List of values, separated by '''|''' (vertical pipe).
     73   * value: Default value (one of the values from options).
     74   * order: Sort order placement.
     75 * '''radio''': Radio buttons. Essentially the same as '''select'''.
     76   * label: Descriptive label.
     77   * options: List of values, separated by '''|''' (vertical pipe).
     78   * value: Default value, one of the values from options.
     79   * order: Sort order placement.
     80 * '''textarea''': Multi-line text area.
     81   * label: Descriptive label.
     82   * value: Default text.
     83   * rows: Height in lines.
     84   * order: Sort order placement.
     85   * max_size: Maximum allowed size in characters (//Since 1.3.2//).
     86   * format: Either `plain` for plain text or `wiki` to interpret the content as WikiFormatting.
     87 * '''time''': Date and time picker. (//Since 1.1.1//)
     88   * label: Descriptive label.
     89   * value: Default date.
     90   * order: Sort order placement.
     91   * format: One of:
     92     * `relative` for relative dates.
     93     * `date` for absolute dates.
     94     * `datetime` for absolute date and time values.
     95
     96If the `label` is not specified, it will be created by capitalizing the custom field name and replacing underscores with whitespaces.
     97
     98Macros will be expanded when rendering `textarea` fields with format `wiki`, but not when rendering `text` fields with format `wiki`.
     99
     100=== Sample Configuration
     101
     102{{{#!ini
     103[ticket-custom]
     104
     105test_one = text
     106test_one.label = Just a text box
     107
     108test_two = text
     109test_two.label = Another text-box
     110test_two.value = Default [mailto:joe@nospam.com owner]
     111test_two.format = wiki
     112
     113test_three = checkbox
     114test_three.label = Some checkbox
     115test_three.value = 1
     116
     117test_four = select
     118test_four.label = My selectbox
     119test_four.options = one|two|third option|four
     120test_four.value = two
     121
     122test_five = radio
     123test_five.label = Radio buttons are fun
     124test_five.options = |uno|dos|tres|cuatro|cinco
     125test_five.value = dos
     126
     127test_six = textarea
     128test_six.label = This is a large textarea
     129test_six.value = Default text
     130test_six.cols = 60
     131test_six.rows = 30
     132
     133test_seven = time
     134test_seven.label = A relative date
     135test_seven.format = relative
     136test_seven.value = now
     137
     138test_eight = time
     139test_eight.label = An absolute date
     140test_eight.format = date
     141test_eight.value = yesterday
     142
     143test_nine = time
     144test_nine.label = A date and time
     145test_nine.format = datetime
     146test_nine.value = in 2 hours
     147}}}
     148
     149'''Note''': To make a `select` type field optional, specify a leading `|` in `fieldname.options` (e.g. `test_five`).
     150
     151=== Reports Involving Custom Fields
     152
     153Custom ticket fields are stored in the `ticket_custom` table, not in the `ticket` table. So to display the values from custom fields in a report, you will need a join on the 2 tables. Let's use an example with a custom ticket field called `progress`.
     154
     155{{{#!sql
     156SELECT p.value AS __color__,
     157   id AS ticket, summary, owner, c.value AS progress
     158FROM ticket t, enum p, ticket_custom c
     159WHERE status IN ('assigned') AND t.id = c.ticket AND c.name = 'progress'
     160  AND p.name = t.priority AND p.type = 'priority'
     161ORDER BY p.value
     162}}}
     163'''Note''': This will only show tickets that have progress set in them. This is '''not the same as showing all tickets'''. If you created this custom ticket field ''after'' you have already created some tickets, they will not have that field defined, and thus they will never show up on this ticket query. If you go back and modify those tickets, the field will be defined, and they will appear in the query.
     164
     165However, if you want to show all ticket entries (with progress defined and without), you need to use a `JOIN` for every custom field that is in the query:
     166{{{#!sql
     167SELECT p.value AS __color__,
     168   id AS ticket, summary, component, version, milestone, severity,
     169   (CASE status WHEN 'assigned' THEN owner||' *' ELSE owner END) AS owner,
     170   time AS created,
     171   changetime AS _changetime, description AS _description,
     172   reporter AS _reporter,
     173   (CASE WHEN c.value = '0' THEN 'None' ELSE c.value END) AS progress
     174FROM ticket t
     175   LEFT OUTER JOIN ticket_custom c ON (t.id = c.ticket AND c.name = 'progress')
     176   JOIN enum p ON p.name = t.priority AND p.type = 'priority'
     177WHERE status IN ('new', 'assigned', 'reopened')
     178ORDER BY p.value, milestone, severity, time
     179}}}
     180
     181Note in particular the `LEFT OUTER JOIN` statement here.
     182
     183Note that option names in trac.ini are case-insensitive, so even if your option name includes uppercase characters:
     184{{{#!ini
     185[ticket-custom]
     186Progress_Type = text
     187}}}
     188you must use '''lowercase''' in the SQL: `AND c.name = 'progress_type'`.
     189
     190----
     191See also: TracTickets, TracIni