Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

For this example we configured a field to get all the data from a table and insert/update the value of a column based on the value of another custom field. So the configuration for the custom field should look like this:

...

Button handy
blanktrue
color#0052CC
nameSend Feedback
linkhttps://docs.google.com/forms/d/e/1FAIpQLScmToBe3vynAlb5fdKwCGxYqnTbDc66sIBgeecG2BuFDuHc7g/viewform?entry.2002826954=How+to+Use+Script+Parameters+-+15487441
widthauto

The concept of script parameters is to allow the SQL or SIL scripts to get data from the UI of the field or even from another fields on the screen or issue. This will allow the query to retrieve different results based on the values of dependent fields.

There are two types of parameters that can be used inside the configuration scripts:

Internal parameters

The internal parameters are needed when you want to use the UI values of the field’s columns. Here is a comparison of how the internal parameters are used in SQL & SIL scripts:

SQL

SIL

syntax

{:columnIndex}

argv[columnIndex]

first columnIndex

1

0

columnIndex is a number that represents the position of the column in the field configuration (Columns)

Note

Notice the internal parameters column index difference between SQL (1-based) and SIL (0-based).

Example

Let’s assume we have the following list of columns for a field configuration:

Image Added

If you want to insert or update a record in the database, you click on the Insert/Update (https://appfire.atlassian.net/wiki/spaces/PSJ/pages/544113815/Using+the+Advanced+Database+Row+Field#Set-the-value-of-a-generic-field) option, you fill in the form values and then you submit it, triggering the run of the INSERT/UPDATE script.

Example of INSERT scripts:

  1. SQL

Code Block
INSERT INTO 

...

countries(id, code, 

...

name, 

...

independence, 

...

gdp_capita, capital, 

...

is_

...

eu) 
VALUES ({:1}, {:2}, {:3}, {:4}, {:5}, {:6}, {

...

:

...

7})
  1. SIL

Code Block
string sql = "INSERT INTO countries(id, code, name, independence, gdp_capita, capital, is_eu) VALUES (?::int, ?, ?, ?::date, ?::real, ?, ?::boolean)";
sql("postgresDB", sql, argv[0], argv[1], argv[2], argv[3], argv[4], argv[5], argv[6]);

Example of UPDATE scripts:

  1. SQL

Code Block
UPDATE 

...

countries SET 

...

code = {:2}, 

...

name = {:3}, 

...

independence = {:4}, 

...

gdp_capita = {:5}, capital = {

...

:

...

6}, is_eu = {:7} 
WHERE 

...

id = {:1}

...

Where {:1}...{:4} are the parameters corresponding to the columns and their values come from the interface.

{issue:customfield_11300} is the set value of the custom field in the issue.

Info

If you are in Edit screen and you want to get the value displayed on the custom field you should use {screen:customfield_11300}

After setting up the scripts and saving the configuration go to an issue and insert/update the field.

Image Removed

...

  1. SIL

Code Block
string sql = "UPDATE countries SET code = ?, name = ?, independence = ?::date, gdp_capita = ?::real, capital = ?, is_eu = ?::boolean WHERE id = ?::int";
sql("postgresDB", sql, argv[1], argv[2], argv[3], argv[4], argv[5], argv[6], argv[0]);

The internal parameters are used to refer the actual values that were filled in the Insert/Update form.

Similarly, let’s take a Search form with inputs that correspond to columns in the configuration:

Image Added

In order to use their values when running the SEARCH script, they will have to be referred to using internal parameters.

Example of SEARCH scripts:

  1. SQL

Code Block
SELECT id, code, name, independence, gdp_capita, capital, is_eu FROM countries 
WHERE code LIKE '%' || {:2} || '%'
  1. SIL

Code Block
string sql = "SELECT id, code, name, independence, gdp_capita, capital, is_eu FROM countries WHERE code LIKE ? || '%'";
string[] vals = sql("postgresDB", sql, argv[1]);
return vals;

External parameters

The external parameters are needed when you want to use the values of another Jira fields.

There are two types of external parameters: issue and screen.

Use issue prefix for parameters if you want to employ the field value that is stored in the Jira issue.

Use screen prefix for parameters if you want to employ the field value that is displayed in the screen. This can be useful when someone is creating a new issue and has not yet submitted it, so the issue value doesn’t exist. Or simply when you want to correlate with the value of that field from the current screen as it might have changed from what is saved in the Jira issue.

Here is a comparison of how the external parameters are used in SQL & SIL scripts:

SQL

SIL

screen syntax

{screen:fieldNameOrId}

argv[“fieldNameOrId”]

issue syntax

{issue:fieldNameOrId}

regular SIL syntax

The fieldNameOrId can refer to:

  • standard variables - This is the list of fields that come out-of-the-box with Jira like assignee, description, summary, etc. For a full list of fields see Standard Variables

  • custom fields - This is a complete list of custom fields from your Jira instance

Example of SEARCH script with external parameters:

  1. SQL:

Code Block
SELECT id, code, name, independence, gdp_capita, capital, is_eu FROM countries 
WHERE name LIKE {screen:summary} || '%'
  1. SIL:

Code Block
string sql = "SELECT id, code, name, independence, gdp_capita, capital, is_eu FROM countries WHERE name LIKE ? || '%'";
string[] vals = sql("postgresDB", sql, argv["summary"]);
return vals;
Note

Important: external parameters need to be explicitly declared in the Script parameters multi-select, otherwise their values will not be interpreted in the script itself

Image Added

The previous script means the values that will be returned by the Search are those database records that have their name column starting with the screen value of the summary Jira standard field. If the issue has ‘Sw’ value for summary, countries like Sweden and Switzerland will both show up in the search results.

Supported fields

Here is a list of fields available to be used as external parameters and their availability (either as screen or issue parameters):

Jira Standard Field

screen availability

issue availability

key

(tick)

(tick)

issueType

(tick)

(tick)

issueTypeId

(error)

(tick)

project

(tick)

(tick)

projectId

(error)

(tick)

summary

(tick)

(tick)

description

(tick)

(tick)

assignee

(tick)

(tick)

reporter

(tick)

(tick)

issueNumber

(error)

(tick)

issueCreator

(error)

(tick)

status

(tick)

(tick)

statusId

(error)

(tick)

dueDate

(tick)

(tick)

resolution

(tick)

(tick)

resolutionId

(error)

(tick)

resolutionDate

(tick)

(tick)

environment

(tick)

(tick)

estimate

(tick)

(tick)

originalEstimate

(tick)

(tick)

created

(tick)

(tick)

update

(tick)

(tick)

priority

(tick)

(tick)

priorityId

(error)

(tick)

securityLevel

(tick)

(tick)

securityLevelId

(error)

(tick)

timeSpent

(tick)

(tick)

workflow

(error)

(tick)

workflowId

(error)

(tick)

components

(tick)

(tick)

votes

(tick)

(tick)

watchers

(tick)

(tick)

labels

(tick)

(tick)

affectedVersions

(tick)

(tick)

fixVersions

(tick)

(tick)

attachments

(tick)

(tick)

parent

(error)

(tick)

parentId

(error)

(tick)

archived

(error)

(tick)

In addition to Jira Standard fields, the following Jira Custom fields are supported in both screen/issue versions: checkboxes, date picker, date time picker, labels, radio, select list (single & multiple choice), text field (single & multi line), url field, user picker (single & multiple user), group picker (single & multiple), version picker (single & multiple), project picker.

On top of that, we also offer support for Advanced Database Row Fields and Power Custom Fields, for both screen & issue parameters.

Table of Contents