Config Helper (experimental)

This is an experimental feature. Recommended only to be used by developers and consultants.

Requirements

Make sure the technical user has Jira Admin and Project Admin permissions on the target projects.
The command reads servers and projects from your .jira-push.yaml. You need at least minimal auth and project details for both serverfrom and serverto.

Note: Starting v1.13.0, the command will continue even when certain permissions are missing (for example, viewing all statuses or workflow schemes). Missing sections will simply be omitted from the report and warnings will be logged.

What it does

Retrieves most configuration details needed to set up a Jira sync, for BOTH the FROM and TO servers defined in your config:

Issue Types (IDs)
Epic Custom Fields (Epic Name and Epic Link)
Project Priorities
Project Statuses per Issue Type
Workflow Schemes and Transitions
- Cloud: transitions are listed directly
- Data Center / Server: a link to the workflow editor with transition IDs is provided
(Optional) Project Users (display name and account ID) when enabled with a flag

Please watch the demo https://www.loom.com/share/63d34d0d510a487ba93a17bc5b65f254?sid=c21dde3e-cde4-4ba2-a5c6-48163bcd2a6b

Usage

Default behavior (no file creation):

BASH

jira-push config get --config /path/to/.jira-push.yaml

Prints a human-friendly report to stdout (and logs). No report file is created by default.

Optional flags:

--report, -r: Write the report to a file.
--report-path <path>: Path for the report. If it’s an existing directory, a timestamped filename is created inside it. If it’s a filename, that exact name is used. If you point to a non-existing directory, the command will error.
--include-users: Include project user data (display names and account IDs) in the report (off by default).

Behavioral notes:

If report file creation fails (e.g., permissions), the command logs a warning and falls back to stdout. The command will not fail in this case.
Cloud next-gen (simplified) projects don’t currently support listing workflow transitions; the report will mention this if applicable.

Examples:

BASH

# Print to stdout only
jira-push config get --config ~/Code/data/jira-push/bsh/.jira-push-mobile.yaml

# Write a timestamped file in the current directory
jira-push config get --report

# Write a timestamped file into an existing directory
jira-push config get --report --report-path ./reports

# Write to an exact filename
jira-push config get --report --report-path /tmp/my-report.txt

# Include project users (names and account IDs)
jira-push config get --include-users

Minimal template config

YAML

serverfrom:
  auth:
    personalaccesstoken: <token-or-password>
  host: <jira-host-from>
  projectkey: <PROJECT_KEY_FROM>
  scheme: https
serverto:
  auth:
    username: <user>
    password: <password or token>
  host: <jira-host-to>
  projectkey: <PROJECT_KEY_TO>
  scheme: https

Output

Depending on your environment and flags, the output may include some or all of the following sections.

Example (Cloud FROM, with epic fields and priorities, and users when --include-users is set):

TEXT

 --- Config For FROM Cloud Server: <host>
Project: <KEY>

Issue Types
Story - 10004
Task - 10067
...

Epic Custom Fields
Epic Name - customfield_10011
Epic Link - customfield_10014

Project Priorities
Highest - 1
High - 2
Medium - 3
Low - 4
Lowest - 5

Project Statuses per Issue Type
# (may be empty if your user cannot view statuses)

Usernames
Jane Doe - 712020:...
John Smith - 6332c7...

No workflow scheme was found for project (<KEY>)

Example (Server/DC TO, with statuses and workflows link):

TEXT

 --- Config For TO Server: <host>
Project: <KEY>

Issue Types
Sub-task - 10000
Epic - 10001
Story - 10002
...

Epic Custom Fields
Epic Name - customfield_10102
Epic Link - customfield_10100

Project Priorities
# If you don’t have access to the Priority Scheme, the report will note this and list generic priorities instead.

Project Statuses per Issue Type
Task
- To Do - 10000
- In Progress - 3
- Done - 10001
...

Transitions
Please go to the link below to view your workflow and click on edit (pencil icon) to view the transition ID's
https://<host>/plugins/servlet/project-config/<KEY>/workflows

 --- End Config For TO Server

Logs and report files

A log file for the command execution is created with a timestamped name, e.g. jirasync-config-get-<timestamp>.log. If logs.directory is configured in .jira-push.yaml, logs go there; otherwise they are written to the current directory.
When --report is used, a human-friendly report file is written, default-named jirasync-config-report-<timestamp>.txt (unless you specify an exact filename via --report-path).

Change summary (v1.13.0)

New flags for improved reporting:
- --report, -r to write the human-friendly report to a file
- --report-path to choose directory or exact filename
- --include-users to include project users in the report
Default behavior now prints the report to stdout (and logs); no file creation by default.
If report file creation fails, the command logs a warning and continues by printing to stdout.
Internally, the report output is buffered for safer writes; we flush once at the end and warn if flushing fails.
Generation continues on non-fatal errors (e.g., insufficient permissions), producing as much information as possible.

Known limitations and suggestions

Validation: The command still performs broader config validation (from the general CLI). In practice you only need minimal server and auth details for config get; we plan to relax validation for this specific command.
Request Type field: The request type custom field is not yet included in the retrieved fields. We plan to add it for Service Desk projects in a future iteration.
Next-gen/Simplified Cloud projects: workflow transitions are not retrieved.

Run via source or binary

BASH

go run main.go config get --config /path/to/.jira-push.yaml
./jira-push config get --config /path/to/.jira-push.yaml

If you need a visual walkthrough, see the demo video linked above.