Jira

The integration connects Buff to your Jira from inside your own network. The team keeps filing tasks and asking questions where it is used to: in the ticket. Buff reads the ticket, drafts a development task from it, and returns the answer as a comment in the same ticket — with a link to the result.

• A question about the code without leaving the ticket

  A tester has filed a ticket “CSV export breaks on Cyrillic” and does not know where to dig. They mention the bot in a comment and ask it to look into it.

  Result. A few minutes later the ticket holds an analysis: where the export is built, why the encoding is lost and what will have to change. Nobody created a task or switched to another interface.

• A development task straight from the ticket

  A product manager described an improvement in a ticket — with a ten-comment discussion where half the requirements appeared along the way. Usually the brief has to be rewritten from scratch.

  Result. Buff reads the whole ticket, together with its comments and history, and drafts a development task from it — you approve the brief in the app. The link to the task goes back into the ticket, so the tracker stays the one place where the team checks the status.

• This happened before — find where exactly

  A request has come in that looks suspiciously like last year’s. Searching by hand with JQL takes a long time, and the only person who remembers it is on holiday.

  Result. The integration searches the selected projects and brings back related tickets: duplicates, past requests about the same subsystem and the tasks the current one depends on — with links.

• The answer where it is expected

  The person who requested the task does not open the Buff interface and has no plans to. They need an answer in the ticket they opened.

  Result. The finished analysis or a link to the pull request arrives as a comment in the original ticket. It is the only tool of the integration that writes anything — and it is unavailable at the stages where the model only reads.

1. @buff, find tickets in the history about the caching problem

   a comment in any ticket of a selected project

   tool: search_issues

   Found 4 tickets about caching: • PROJ-218 “Catalogue cache is not reset after a price change” — closed 12.03, fixed in CacheWarmer • PROJ-341 “Empty /search responses for the first 30 seconds after a deploy” — closed 04.06, cache warm-up • OPS-77 “Redis eats memory during exports” — open, discussion about TTL • PROJ-402 “Duplicates in results after invalidation” — open, similar to the current one

2. @buff, find out why Cyrillic breaks when exporting to CSV

   a comment in the ticket with the problem itself

   tool: get_issue + code tools

   I read the whole ticket together with its discussion and traced it through the code. The export is built in ExportService.buildCsv; the file is served without a BOM and with a text/csv header without a charset — Excel on Windows reads such a file as cp1251. I attached the analysis with the places in the code as a document and posted a link to it here.

3. @buff, create a development task from this ticket

   a comment in the ticket

   tool: get_issue

   The task is created: it carries the description, the requirements that surfaced in the comments and the constraints from the change history. The link to the task is in the reply comment, so the status is visible without leaving the tracker.

4. @buff, research where the delay in the report comes from

   a comment in the ticket — this is how deep research starts

   tool: get_issue

   The word after the mention picks the work: without it — a short answer, “research” — deep research with a document, “task” — a draft development task. Work starts only on a direct mention: a label or a change to the bot field does not start it — those are set by rules and bulk edits, not by a person who decided to order work.

5. @buff, what has already been discussed in this ticket?

   a comment in a ticket with a long thread

   tool: get_issue

   A short summary of the discussion: what was asked for originally, which requirements were added along the way (and in which comment), what was agreed and what remains unresolved. Useful when a ticket is six months old and has thirty comments.

1. Step 1

   Installation takes one click

   Open the “Marketplace” section on the connector’s local page. Before installing you can see what the integration will get: the addresses it will be able to reach, which credentials it will ask for, whether it will receive webhooks and how many tools the model will see. You click “Install” — the connector downloads a signed bundle from our registry and checks the signature before writing anything to disk.

   Connector

   

   ← scroll the frame →

2. Step 2

   Setup is a form from the integration itself

   Next you add a connection: the address of your Jira, the project keys, how the bot is addressed and a token. We did not write the form for Jira — it is built from the schema the integration declares about itself, so setup looks equally clear for any of them. The token stays in the connector: the integration does not see it, the connector inserts it into outgoing requests itself.

   Connector

   

   ← scroll the frame →

3. Step 3

   The same from the command line

   Installing without a GUI is an equal option, not a fallback: `connector install jira`, then `connector instance add jira --config base_url=… --config project_keys=PROJ`. On a server without X you do the same and get the same result.

4. Step 4

   A connection’s version does not change by itself

   A connection is pinned to a specific version of the integration. A new version appears in the catalogue and waits: updating is your action, not ours. When updating, the connector first checks that the settings already entered fit the new version and refuses, naming the missing field — instead of breaking a working integration with an “update” button.

5. Step 5

   A machine without internet

   If the machine has no way out at all, the catalogue and bundles are moved as files: a signed set is assembled where there is a network and put on a medium. The signature check at installation is the same — this kind of transfer is exactly what it is for. Alternatively, the whole registry can be mirrored to your own Harbor or Nexus with the connector pointed at the mirror.

6. Step 6

   Several Jiras — several connections

   The same Jira for different projects, or two different Jiras, are two connections of one integration. Each has its own credentials, its own list of projects and its own separate process under its own OS user. Renaming breaks nothing: a connection lives under an identifier, not under a name.

   Connector

   

   ← scroll the frame →

7. Step 7

   Events arrive on their own

   After setup there is nothing to start: the integration watches the selected projects itself. Polling runs on a schedule and needs no open ports — inside a closed perimeter it is the only option that works. If you want it faster, turn on event receiving in the connector: the address is set once for the whole machine, and the connection keeps only a switch. The connector issues the link for the tracker itself — nobody types it by hand, and it is bound to the connection’s identifier, so renaming does not break it. The connector generates the secret inside the link and does not show it in the settings.

   Connector

   

   ← scroll the frame →

The integration runs as a separate process under its own operating system user: it does not see the connector’s key, does not read the files of other connections and cannot reach the network past the connector. More in the security section.

• Jira Data Center or self-hosted Server. Jira Cloud has a separate integration.
• A Personal Access Token (Jira 8.14 and later), or a login and password for older Server versions.
• Network access from the connector’s machine to Jira — nothing needs to be opened from your network to the outside.
• A connector run with the right to create a separate OS user for the integration (root or CAP_SETUID).

Does the Jira token go to your cloud?

No. It is stored on the connector’s machine and never leaves it. The integration does not see it either: the connector inserts the token into the outgoing request itself.

Can the integration reach anything other than our Jira?

No. The integration goes out only through the connector and only to addresses derived from the setup fields — in this case, from the address of your Jira. The connector rejects everything else.

Can the bot start work on its own, without being addressed?

No. Work is started only by a direct mention — the bot mentioned in a comment. Labels and field changes do not count: they are set by rules and bulk edits, and that would lead to work nobody ordered but that is billed. Assigning a ticket to the bot is a way of addressing it, but it can be automatic too, so it is off by default and turned on by a separate connection setting.

Can the model accidentally write to a ticket during analysis?

No. At the reading stages only the tools marked as reading are available. add_comment does not get there, and the connector checks that on its side, not we on ours.

Do I need to open a port for webhooks?

Not necessarily. Polling Jira always works and needs no open ports; receiving events is a speed-up for those who have somewhere to direct it. The port is opened by the connector, one for all connections; the integrations themselves open no ports at all.

How is the integration updated?

A connection is pinned to a specific version — updates do not happen by themselves. A new version appears in the catalogue, and you decide when to move to it. Before the move the connector checks that your settings fit the new version and refuses, naming the missing field.

What if our system can only send a webhook and there is nothing to poll it with?

That is a working case. The integration can parse an incoming call and turn it into an event without calling the source’s API at all — this is how internal services that can only push are integrated, and changes that are no longer in the current state. The receiver, the secret and the signature are still on the connector’s side: the integration itself opens no port.

How quickly does an answer to a mention in a ticket arrive?

Without event receiving — within the polling interval, seconds to tens of seconds before the request is accepted; the answer itself takes as long as the work takes. With receiving turned on, the request is accepted almost as soon as the tracker sends the call.

Can the bot answer the same question twice?

No. Each event has its own identifier, the connector moves the read mark only past delivered events, and the platform rejects repeats. An agent restart or a dropped connection does not turn into a second answer.

What if the machine has no internet access?

It works. The catalogue and bundles can be moved as files in a signed set, or our registry can be mirrored to your own Harbor or Nexus. The signature is checked either way — this kind of transfer is what it exists for.