GitHub integration

The GitHub integration turns bug reports into trackable GitHub issues without leaving the ticket, and keeps both sides in sync.

Connecting GitHub

The integration uses the Joely GitHub App: you install it on the repositories you choose, with least-privilege scoped permissions, no personal access token involved. You then select which repositories are available for issue linking, and can re-fetch the list at any time.

• Configuration requires the Configure GitHub integration permission; disconnecting requires Disconnect GitHub.
• A project can connect several GitHub accounts (personal and organizations) on eligible plans.

Creating an issue from a ticket

Staff with the Manage GitHub issues on tickets permission can create a GitHub issue directly from a ticket:

• AI drafts the issue: title and description are generated from the ticket conversation, so the issue reads like a clean bug report instead of a chat log.
• You pick the target repository among the ones you enabled.
• One issue per ticket: a ticket is linked to at most one GitHub issue. To switch, unlink first.

Linking an existing issue

If the bug is already tracked, link the ticket to the existing GitHub issue instead of creating a duplicate. Unlinking is always possible (same permission).

Duplicate detection

On eligible plans, AI compares new tickets against your open GitHub issues and flags probable duplicates, so a known bug reported by ten customers becomes one issue with ten linked conversations, not ten issues.

Status sync

The link is live in both directions: changes to a linked GitHub issue (such as closing it) are reflected on the ticket in real time via webhooks. Support always knows whether the fix shipped without checking GitHub.

Automatic status transitions

When auto-update status from GitHub is enabled in the GitHub integration settings (off by default, per project), Joely advances linked tickets through their lifecycle as you work, following GitHub's recommended flow:

• Issue closed as completed → Awaiting release. When a linked issue is closed as completed, typically because a pull request with Closes #123 was merged, every ticket linked to it moves to Awaiting release. Issues closed as not planned are ignored.
• Release published → Resolved. When you publish a release on the repository, every Awaiting release ticket whose linked issue lives in that repository moves to Resolved, which triggers the customer's satisfaction survey and Discord notification.

A few rules worth knowing:

• It only ever moves tickets forward. A ticket already Resolved or Closed is never pulled back to Awaiting release by a later issue event.
• It depends on the standard GitHub workflow. If an issue is left open, closed without the completed reason, or never linked with Closes #N, nothing happens; the signal simply never fires. You can always change the status manually.
• It is project-scoped. The toggle requires the Configure GitHub integration permission and applies to that project only.
• Enabling is checked. Turning the toggle on verifies that the connected GitHub App installation is actually subscribed to the Issues and Release events and holds the Contents permission. If it isn't, enabling is blocked with a prompt to re-approve the App, so the automation never silently does nothing.

Package-to-repository linking

You can map each Tebex package to the GitHub repository that contains its code. When a ticket is linked to a package, issue creation pre-targets the right repository. AI can suggest the best matching repository for each package, with batch auto-linking above a confidence threshold.