Explained

Below you will find a complete list of the Actions and Parameters available in the Bob Swift Command Line Interface (CLI).

Actions

These are the keywords that tell the CLI what action to take. The actions listed correspond to nearly everything you can do via the screens on the app by pointing, clicking, and typing text into fields. You see a pattern to the beginning or prefix that is an action verb such as: add, copy, export, get, modify, move, remove, run, store, update, and more depending on the app. The ending or suffix to the action name is the noun or object of the verb such as attachment, comment, label, permission, user, and more depending on the app. For example, the action addComment adds a comment to an item in the app. Not all actions are available for all apps because not all apps have the same features.

Parameters

These tell the CLI the specific details needed to perform an action. Some actions work without any additional details, but most require one or more parameters and accept additional optional parameters to perform its task. In fact, the CLI requires at least one special parameter named action (that tells what action to perform), without which CLI simply displays help with some example actions. Parameters do not have prefixes like actions and are often very specific to the app for the action. 

Consider an example action getServerInfo that requires details about the app (or server) from which the information is retrieved. This is accomplished using the server parameter. The getServerInfo action also accepts optional parameters such as outputFormat, dateFormat, file, append, and encoding.

Example

An action and its parameters put together unlock the power to get things done with your apps. Here is an example of retrieving information about the Bob Swift Jira app in a multi-line format:

acli --action getServerInfo --server https://bobswift.atlassian.net --outputFormat 2

Action output:

Server info

Product . . . . . . . . . . . : Jira
Version . . . . . . . . . . . : 1001.0.0-SNAPSHOT
Base URL  . . . . . . . . . . : https://bobswift.atlassian.net
Title . . . . . . . . . . . . : Jira for Bob Swift Atlassian Apps
Build . . . . . . . . . . . . : 100118
Build date  . . . . . . . . . : 12/22/19 11:26 PM
Current time  . . . . . . . . : 
License information . . . . . : Not available for this Cloud instance.
Client  . . . . . . . . . . . : jira
User  . . . . . . . . . . . . : anonymous
Response time (milliseconds)  : 739

On this page

Related pages

Actions

Generating page properties report...

Parameters

Generating page properties report...

Parameter Tips 


Common parameters

A few common parameters are available that are not specifically listed as optional parameters for each action: help, verbose, debug, quiet, special, dateFormat, dateFormat2, and outputType. Similarly for database related parameters that are optional for all get list actions: url, dbUser, dbPassword, database, driver, dbJar, host, port, dbCreateTable, dbTable, dbTableKeys, afterSql, and propertyFile.

Tips

  • To get help for a specific action, type the action followed by --help - example: --action getProjectList --help
  • Use double dash for multi-letter parameters - example: --help
  • Use single dash for single letter parameters indicated in the Short column in parameter help - example: -v
  • When parameters are specified, most need a value as indicated by a check in the Value column in parameter help - example: --action addPage
  • Some parameters are flags (boolean) and must not be followed by a value - example: --verbose
  • Parameter names are case sensitive, but, action values are not - example: --userid is invalid but --action addpage is equivalent to --action addPage
    • An incorrect case parameter will result in an unknown parameter error and show action help with correctly cased parameter (9.8 or higher)
  • Some parameters become required once a specific action is chosen. This is indicated in the action help text as required.
  • Some parameters have both short (one letter) and long (more than one letter) parameter names - example: -a or --action are the same and cannot both be specified
  • Some parameters have default values, if so, they are indicated in the help text
  • Values that contain blanks or some special characters (platform specific) must be enclosed by double quotes - example: --title "this is my title"
  • Quoting rules in commands can vary by terminal environment (sad):
    • Windows command terminals or run action scripts for all platforms: embedded double quotes within a double quoted string must be escaped by doubling the double quote - example: –common "-a addComment --comment ""This is an example of a double quoted string inside a double quote"" "
    • Linux and Mac/OSX command terminals require standard Linux style escaping: embedded double quotes within a double quoted string can be escaped with a \ - example: –common "-a addComment --comment \"This is an example of a double quoted string inside a double quote\" "
    • Run CLI Actions usage: embedded double quotes within a double quoted string can be escaped by doubling the double quote (first example above)
    • A single quote sometimes can used in place of a double quotes on some command terminal environments - example: –common '-a addComment --comment "This is an example of a double quoted string inside a double quote" '
  • Some parameters allow entry of a comma separated list of values, values containing a comma must be enclosed in single quotes - example: --custom "'first:a,b,c', second:x". Embedded single quotes within a quoted string must be doubled
  • Some text fields support the automatic conversion of " \n " (blanks are significant) to be replaced with a new line character - example: --description "A multi-line text field: \n # line 1 \n # line 2"

Special parameter

Some special characters are difficult to deal with or make action text very complicated. This is because they have special meaning in either the OS command terminal handling, the tool's command line parsing, or the tool's use of separators (like comma or colon separated lists). As a convenience to avoid some of these nasty situations, a special parameter was implemented to allow alternate characters to be used instead of (or in addition to) the problematic characters within parameter values. The choice of what special characters to use depends on the content so that you do not have conflicts with intended content. The special parameter works by the user providing a order specific alternate character. The alternative character is replaced with the real character after all other parsing occurs. It is implemented for many action parameters that are problematic in this area. Not all situations are covered, but, that will improve as other use cases are identified.

PositionCharacterCharacter nameSuggested alternateUsage
1,comma
Some parameters use comma separated lists.
2:colon#Some parameters use colon separated values.
3@at sign
Replacement variables syntax: @...@.
4'single quote
Used in separated lists to cover cases where content contains separator.
5"double quote~Parameters containing blanks.
6^caret
Substitution double quote indicator: ^^...^^. See ACLI-673 for details. 

A blank in any position is ignored (no alternate provided).

Example: –special " #  ~" provides alternates for colon and double quote. 
         --common "--findReplace ~something to find containing a : (colon)#replacement~"

Character Set

User and password values should be in the ISO-8859-1 character set. Also avoid characters that require escapging on your OS command terminal. Non standard characters will result in an authorization error similar to: User is not authorized to perform the request.