Skip to Content

Search the Live Tenant

ajat search queries the configured Jira tenant through the Automation API and returns matching rule summaries. Use it when you want a fresh answer — “which rules are currently DISABLED?” — without first running a full ajat export.

It is intentionally a thin command. It returns the UUID, name, state, owner, actor, labels, and scope of each matching rule — the summary, not the rule body. The richer matching needed for bulk operations lives on the local export catalog and is available through the ajat rule command family.

ajat works with Atlassian Jira Cloud Automation only. It does not support Jira Server or Jira Data Center. ajat search calls the live Jira Cloud tenant, so it requires valid credentials and a working configuration — run ajat doctor first if you are unsure.

Usage

ajat search [--trigger <type>] [--state ENABLED|DISABLED] \ [--owner <accountId|email|name>] [--scope <ari>]... \ [--limit <n>] [--page-size <n>] \ [--format table|json]

All filters are optional and are ANDed together server-side. Passing no filters lists every rule in the tenant.

Flags

FlagDefaultDescription
--trigger(none)Filter by the rule’s trigger component type (e.g. jira.issue.created).
--state(none)Filter by rule state: ENABLED or DISABLED.
--owner(none)Filter by the rule’s owner (its authorAccountId). An email address or display name is looked up in Jira and must match exactly one user.
--author(none)Deprecated alias of --owner; prints a warning. See Owner, not actor.
--scope[]Filter by rule scope ARI. Repeatable: one search runs per ARI and the results are merged, so a rule carrying any listed ARI is shown once.
--limit0Stop after returning at most this many matches. 0 means no cap.
--page-size100Cursor page size for the underlying API loop (1–100).
--formattableOutput format: table or json.

Examples

# Every ENABLED rule whose trigger is issue.created ajat search --state ENABLED --trigger jira.issue.created # Every DISABLED rule, capped to the first 10 (spot-check) ajat search --state DISABLED --limit 10 # Rules owned by a person, by email or by account ID ajat search --owner jane@acme.com ajat search --owner 557058:f58131cb-b67d-43c7-b30d-6b58d40bd077 --state ENABLED # As JSON for scripting ajat search --owner jane@acme.com --format json # All rules carrying either of two scope ARIs ajat search --scope ari:cloud:jira::site/AAA --scope ari:cloud:jira::site/BBB

Owner, not actor

A rule has an owner (the account that created it, authorAccountId) and an actor (the account it runs as). The Automation API can filter by owner only; it has no filter for the actor.

Before v1.0.8, --author was documented as an actor filter and sent a field the API does not recognise. The API ignored it, so --author returned every rule in the tenant; --scope had the same defect. Both are fixed: --owner filters by owner, --scope filters by scope, and --author is kept as a deprecated alias of --owner that prints a warning.

An email address only resolves when Jira shows it: users with a private profile are found by display name or account ID instead. When a name matches several people, the error lists them with their account IDs; pass one of those. The lookup needs the read:jira-user scope, the same one ajat export --resolve-users uses.

To find rules that run as an account, use the local catalog: ajat rule … --actor <accountId> against an export.

Output formats

Table (default)

A summary header echoes the active filter, followed by a UUID / Name / State / Owner / Scope table. Owners show as display names when the token can resolve them, and as account IDs otherwise:

Search trigger : jira.issue.created state : ENABLED matches : 17 UUID Name State Owner Scope ──────────── ───────────────────── ─────── ────────── ────── 11111111-… Auto-triage incoming ENABLED Jane Doe global ...

JSON

A single self-describing object containing the filter echo plus the matched summaries — ideal for piping to jq:

ajat search --state DISABLED --format json | jq '.matches | length'
{ "filter": { "owner": "557058:f58131cb-…", "ownerQuery": "jane@acme.com", "state": "DISABLED" }, "matches": [ { "actorAccountId": "557058:9c32…", "authorAccountId": "557058:f58131cb-…", "labels": ["triage"], "name": "Auto-triage incoming", "ruleScopeARIs": [], "state": "DISABLED", "updated": 1772715265.948, "uuid": "11111111-…" } ] }

The filter echo carries owner (the account ID searched for), ownerQuery (what you typed, when it had to be resolved), and scopes. Earlier versions echoed actor and ruleScopeARIs instead.

Because the JSON stays self-describing, scripted follow-up is straightforward:

# Collect the UUIDs of every rule one person owns ajat search --owner jane@acme.com --format json | jq -r '.matches[].uuid'

When to use search vs. export + reports

ajat search hits the live API and returns summaries; ajat export writes a full local snapshot that reports and ajat rule selectors consume. Reach for each one as follows.

Use ajat search when:

  • You do not have a recent export on disk and only need to inspect, not mutate.
  • You want to verify a recent change without re-exporting.
  • You only care about UUID, name, state, owner, actor, labels, and scope — the summary endpoint does not return conditions or component schemas.

Use ajat export plus reports when:

  • You need the full rule bodies — triggers, conditions, actions, branches, labels, and integration targets.
  • You want offline, shareable analysis (inventory, collision, consistency, risk, workflow) with no live Jira dependency.
  • You are preparing for bulk operations, drift review, restore, or an audit.

For bulk mutation — enable, disable, delete, or scope updates — keep using the ajat rule commands against a local export. Selectors across label, name pattern, actor, and component count have no API-side equivalent, so ajat search cannot drive them.

Exit codes

CodeMeaning
0Search completed (even with zero matches).
1Bootstrap or configuration failure.
130Interrupted by SIGINT / SIGTERM.
  • ajat export — full snapshot to disk; what reports and bulk-rule commands consume.
  • ajat rule — bulk mutations selected from the local catalog.
  • Reports — five self-contained HTML reports over an export snapshot.
  • Utilities — doctor and the rest of the diagnostic surface.
Last updated on