Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »


The grid initialization query (specified with the gd.query property) can be parameterized using issue specific values. These values are used when the grid is instantiated for the specific issue or when the grid query is refreshed. The grid will not be refreshed when for instance the issue is assigned to a different user. More details on the refresh behavior is available on the Grid reload page.

  • Issue specific
    • issue:id
    • issue:key
    • issue:status
    • issue:summary
    • issue:resolution
    • issue:components
    • issue:fixversions
    • issue:affectversions
    • issue:createdate
    • issue:resolutiondate
    • issue:updatedate
    • issue:duedate

    • issue:type

      A number of issue fields such as issue:id, issue:type and issue:key are only available after the issue is created. Errors in the log will be raised, when creating an issue with a grid which is based on these values,

  • Parent issue specific (available only since TGE v1.19.0)
    • parent:id
    • parent:key
    • parent:status
    • parent:summary
    • parent:resolution
    • parent:components
    • parent:fixversions
    • parent:affectversions
    • parent:createdate
    • parent:resolutiondate
    • parent:updatedate
    • parent:duedate
    • parent:type
  • Assignee related
    • assignee:id
    • assignee:fullname
    • assignee:email
    • assignee:emaildomain
  • Reporter related
    • reporter:id
    • reporter:fullname
    • reporter:email
    • reporter:emaildomain
  • Projectlead related
    This is actually the project lead of the project containing the issue
    • projectlead:id
    • projectlead:fullname
    • projectlead:email
    • projectlead:emaildomain
  • Project related
    • project:key
    • project:name
    • project:url
  • Current Fix Version related
    • currentfixversion:name
    • currentfixversion:releasedate
    • currentaffectversion:name
    • currentaffectversion:releasedate

  • Current user
    • currentuser:id
    • currentuser:fullname
    • currentuser:email
    • currentuser:emaildomain

  • Customfield related
    Single value customfields
    • customfield:<id of the customfield>
      When the customfield is changed a refresh is automatically triggered

    Multiple value customfield (e.g. Multiuser picker, multigroup picker, multiselect)
    • customfield.<id>.<'all' or the index of the value>.<'name' or 'value'>
      When a customfield with multiple values is needed, one might use this format of the placeholder. 
      The third part of the configuration (<'all' or the index of the value>) defines if all values should be retrieved from the multivalue customfield, or a single, specified by its index.
      The fourth part of the configuration (<'name' or 'value'>) allows the user to specify if he/she wants to retrieve the object's name or actual value. You can use the following guide to decide:
      • Multiple user picker (value - username, name - display name)
      • Multiple group picker (value - group name, name - group name). There is no way to get a group id from Jira API, so in this case 'value' alias will return the same as 'name' returns
      • Multiple select (value - id, name - option name)
      • Cascading select (value - id, name - option name)
      • Multiple version picker (value - id, name - version name)
      • Checkboxes (value - id, name - option name)
      • Multi Level Cascade Field (value - value mapped by storeColumn property, name - option label (mapped by viewColumn property)). 
        For Multi Cascade field we also support level's name in the third part of the configuration. (e.g. {customfield.12345.country.name})

        Usecase: In case of a  multipicker customfield with ID 12345 that contains two values ('Belgium' and 'France'), you can use the following placeholders
      • {customfield.12345.all.value} returns 32145, 23145
      • {customfield.12345.all.name} returns 'Belgium', 'France'. It is important to use single quotes instead of double quotes, because double quotes cause errors in some databases
      • {customfield.12345.1.value) returns value of the first selected element
      • {customfield.12345.1.name) returns name of the first selected element

Note that not all customfields are supported. 

We are trying to support all custom fields. Or at least as many as possible.
Custom field placeholder will be populated with string representation of the custom field value, stored in the database. In most of cases it is populated with the value, that is displayed on issue page. 

You can face some problems with custom field which store their value in unusual way or allow to select multiple values.
Third party custom fields (like "nFeed", "TGE" itself) can use absolutely different approaches for storage of their values. "nFeed" stores them as XML, TGE stores only number of the rows in tge grid in the standard Jira tables. So such fields cannot be referenced in placeholders. If you do want to use them in queries, handle their values using pure SQL instead of placeholder. Here is an example for Multiple Select type: Initializing rows from a multi select custom field.

The multivalue customfields placeholder supports auto-reloading of grid on Create and Edit Issue screens. However, auto-reloading can fail for multiuser, multigroup, and version pickers since they do not trigger any change event when using popup for selection.




  • No labels