Add Enterprise Data Center integration guides

[ak684]

Summary

• add Enterprise setup guide for Jira Data Center
• add Enterprise setup guide for Bitbucket Data Center
• add Enterprise nav links and quick-start cards for Data Center integration setup
• add Jira Data Center and Bitbucket Data Center screenshots for the setup flows

Test

• jq empty docs.json
• git diff --check -- docs.json enterprise/index.mdx enterprise/quick-start.mdx enterprise/integrations/jira-data-center.mdx enterprise/integrations/bitbucket-data-center.mdx
• local Mintlify preview: /enterprise/integrations/jira-data-center, /enterprise/integrations/bitbucket-data-center, /enterprise/quick-start, and /enterprise
• local image checks returned 200 for the Jira manual webhook screenshot and both Bitbucket OAuth screenshots

[mintlify]

Preview deployment for your docs. Learn more about Mintlify Previews.

Project	Status	Preview	Updated (UTC)
all-hands-ai	🟢 Ready	View Preview	May 27, 2026, 4:59 PM

💡 Tip: Enable Workflows to automatically generate PRs for you.

[all-hands-bot]

✅ Review complete.

This review was performed through OpenHands Cloud Automation. You can log in and view the conversation here.

[all-hands-bot]

Summary

This PR adds two new Enterprise integration guides (Jira Data Center and Bitbucket Data Center) plus a screenshot for the LLM configuration dropdown. The content of both guides is thorough and well-structured: clear prerequisite lists, step-by-step Admin Console instructions, distinct Warnings/Notes for common pitfalls (https:// in domain fields, etc.), and comprehensive troubleshooting tables. The quick-start generalization from Anthropic-specific to provider-agnostic is a good improvement.

One navigation issue in docs.json needs fixing before merge — enterprise/analytics and enterprise/external-postgres are left as ungrouped orphans after this change restructures everything else into named groups. See inline comment.

This review was generated by an AI agent (OpenHands) on behalf of the user through OpenHands Automation. View conversation

[all-hands-bot]

✅ Review complete.

This review was performed through OpenHands Cloud Automation. You can log in and view the conversation here.

[all-hands-bot]

Both integration guides are thorough and well-organized — clear prerequisites, step-by-step Admin Console instructions, consistent use of <Warning>/<Note> callouts for common pitfalls, and comprehensive troubleshooting tables. The quick-start provider-agnostic improvements and the docs.json navigation restructuring are clean.

Note on the existing review: The prior CHANGES_REQUESTED review flagged enterprise/analytics and enterprise/external-postgres as orphaned pages. This is not accurate — in the current branch both pages are correctly placed inside the "OpenHands Enterprise" group in docs.json. No fix is needed there.

A few inline suggestions below for clarity.

This review was generated by an AI agent (OpenHands) on behalf of the user through OpenHands Automation. View conversation

[all-hands-bot]

✅ Review complete.

This review was performed through OpenHands Cloud Automation. You can log in and view the conversation here.

[all-hands-bot]

✅ Review complete.

This review was performed through OpenHands Cloud Automation. You can log in and view the conversation here.

[all-hands-bot]

🟡 Acceptable — Two high-quality enterprise integration guides with comprehensive prerequisites, numbered Admin Console steps, appropriate <Warning>/<Note> callouts for common pitfalls, and thorough troubleshooting tables. The docs.json restructuring and quick-start generalization are clean. A few items below before this is merge-ready.

---

Status of Prior Review Threads

Several concerns from earlier reviews are already resolved in the current branch — those threads can be closed:

• ✅ docs.json group structure: enterprise/analytics and enterprise/external-postgres are correctly inside the "OpenHands Enterprise" group. No orphan pages. The first review's CHANGES_REQUESTED on this point was incorrect.
• ✅ REPO_ADMIN Note in Bitbucket DC guide: The <Note> explaining why the scope is required is already present.
• ✅ Jira OAuth scope language: Already reads "When prompted for OAuth scopes, select WRITE" — prescriptive as suggested.
• ✅ Repository: format clarification: Already includes "OpenHands looks for a line starting with Repository: followed by the org/repo slug."

---

[CRITICAL ISSUES]

[enterprise/integrations/jira-data-center.mdx, Lines 134–137] Jira webhook signing mechanism is unverified

The manual setup section instructs admins to "paste the signing secret into Jira's webhook secret field" and states that "Jira uses that secret to sign deliveries with the x-hub-signature header that OpenHands verifies."

Jira Data Center global webhooks do not natively sign payloads with HMAC — there is no built-in "webhook secret field" in Jira's global webhook configuration UI. Jira simply POSTs to the URL without an HMAC signature header. This was flagged in a prior inline review comment and remains unaddressed.

Before merge, please clarify the actual delivery mechanism. Possible correct approaches:

• The signing secret is embedded as a query parameter in the webhook URL (common workaround), in which case the instruction should say "the secret is already encoded in the webhook URL shown above — paste only the URL into Jira, not the secret separately"
• This relies on a specific Jira Data Center version or plugin that adds signing support, in which case the Prerequisites section should call out that version/plugin requirement

---

[IMPROVEMENT OPPORTUNITIES]

See inline comments for two new observations not covered by prior reviews.

---

[RISK ASSESSMENT]

• [Overall PR] ⚠️ Risk Assessment: 🟢 LOW

Documentation-only change. No executable code paths, APIs, or data structures modified. The only risk is technical inaccuracy in the Jira webhook signing description, which could send enterprise admins on a frustrating debugging path. No production system behavior is altered by this PR.

VERDICT:
⚠️ Hold for clarification: Core content is solid and most prior concerns are resolved. The Jira webhook signing mechanism needs one clarifying sentence (or a concrete correction) before merge — enterprise admins will hit a wall otherwise.

KEY INSIGHT: The Jira manual webhook setup instructions describe a Jira-side signing secret field that does not exist in standard Jira DC; this is the only remaining blocker.

---

Improve this review? If any feedback above seems incorrect or irrelevant to this repository, you can teach the reviewer to do better:

1. Add a .agents/skills/custom-codereview-guide.md file to your branch with the /codereview trigger and the context the reviewer is missing. See the customization docs for the required frontmatter format.
2. Re-request a review — the reviewer reads guidelines from the PR branch, so changes take effect immediately.

Was this review helpful? React with 👍 or 👎 to give feedback.

This review was generated by an AI agent (OpenHands) on behalf of the user through OpenHands Automation. View conversation

Addressed in commit 49e8cc2: enterprise/analytics and enterprise/external-postgres are grouped under OpenHands Enterprise, and the Jira OAuth scope wording was made prescriptive. A later all-hands-bot review confirmed the prior navigation concern is no longer accurate.

[all-hands-bot]

Review: Add Enterprise Data Center integration guides

Well-structured, comprehensive guides that will genuinely help Enterprise admins configure these integrations. The coverage of prerequisites, step-by-step setup, <Warning>/<Note> callouts, and troubleshooting tables makes these among the more thorough integration guides in the docs.

Already Addressed

The <Note> explaining why REPO_ADMIN is required is already present in bitbucket-data-center.mdx (lines 49–53), so the previous inline suggestion on that point is already reflected in the file.

Open Issues from Previous Reviews

Two items flagged in earlier reviews are still open and worth resolving before merge:

1. 🟠 docs.json grouping — enterprise/analytics and enterprise/external-postgres are left outside any named group after this PR, sandwiched between "OpenHands Enterprise" and "Integrations". This may render incorrectly in Mintlify. Moving them into the "OpenHands Enterprise" group would fix it.

2. 🟠 Jira webhook signing secret (line 130 in jira-data-center.mdx) — Jira DC's webhook form does not have a dedicated "signing secret" field the way GitHub does. Users following the manual setup path need explicit guidance on exactly where to enter (or embed) that secret value.

New Observations (inline below)

• Terminology inconsistency in the Bitbucket bot-token section: "HTTP access token" and "PAT" are used interchangeably within a few lines.
• Ordering inconsistency: the docs.json nav lists Bitbucket before Jira, but the quick-start.mdx CardGroup lists Jira before Bitbucket.

Strengths

• Consistent structure across both guides (prerequisites → OAuth app → bot token → admin console → trigger → troubleshoot)
• Troubleshooting tables cover the most common failure modes with precise checks (TLS, network reachability, domain-format mistakes)
• The security callout that the admin PAT is used once and immediately discarded is a good trust-builder for security-conscious admins
• Screenshots align closely with the UI steps they illustrate
• <Warning> components correctly pre-empt the two easy config mistakes: including https:// in the Bitbucket domain field, and omitting https:// from the Jira Base URL

This review was generated by an AI agent (OpenHands) on behalf of the user through OpenHands Automation. View conversation

[all-hands-bot]

✅ Review complete.

This review was performed through OpenHands Cloud Automation. You can log in and view the conversation here.

[all-hands-bot]

Review: Add Enterprise Data Center integration guides

These two integration guides are well-structured, comprehensive, and ready for production use. The coverage of prerequisites, Admin Console configuration steps, <Warning>/<Note> callouts for common pitfalls, and troubleshooting tables makes them among the more complete integration guides in the docs. The quick-start generalization away from Anthropic-specific language is a clean improvement.

---

Correcting Prior Review Inaccuracies

Several concerns raised in earlier reviews are not issues in the current branch. Closing the loop here to avoid further confusion:

• ✅ docs.json grouping — enterprise/analytics and enterprise/external-postgres are inside the "OpenHands Enterprise" group in this PR. They are not orphaned. The diff shows both pages nested correctly within that group alongside enterprise/index, enterprise/enterprise-vs-oss, enterprise/quick-start. The earlier CHANGES_REQUESTED and subsequent re-raises of this concern were incorrect.
• ✅ Card order inconsistency — Both docs.json and the quick-start.mdx CardGroup list Bitbucket Data Center before Jira Data Center. No ordering mismatch exists in the current diff.
• ✅ REPO_ADMIN Note — Present at lines 49–53 of bitbucket-data-center.mdx, clearly explaining that the scope is used only for repo listing and webhook management.
• ✅ Bitbucket token terminology — The current diff consistently uses "HTTP access token" throughout the Bitbucket guide. No PAT/HTTP-access-token inconsistency.
• ✅ Jira OAuth scope language — "When prompted for OAuth scopes, select WRITE." is already prescriptive; no "if Jira asks" ambiguity remains.

---

Genuinely Open Items

1. Minimum version requirements (both guides)

Neither guide mentions the minimum Bitbucket DC or Jira DC version required for OAuth 2.0 Application Links with the "External application / Incoming" flow. Admins on older installations will hit the missing settings and have no version guidance. Adding a one-liner (e.g., "Requires Bitbucket Data Center 7.21 or later") in the Prerequisites section would prevent unnecessary support cases.

2. Repository reference scope in Jira integration (jira-data-center.mdx — Trigger section)

The guide instructs Jira users to add Repository: Acme/web-app in the issue and states OpenHands "looks for a line starting with Repository: followed by the org/repo slug." It is not specified which SCM provider this slug refers to. For Enterprise installations that have both Bitbucket Data Center and GitHub connected, it is ambiguous whether this slug targets a GitHub repository, a Bitbucket DC repository, or another connected provider. A sentence clarifying the expected format (e.g., "use the same org/repo format as configured in your connected source control provider") would help prevent user confusion.

3. Jira webhook signing — already handled

The prior inline comment questioning whether Jira DC supports webhook signing is addressed in the current guide: the manual-setup Accordion documents the configuration.SECRET property in the Jira webhook REST API, with a fallback note when the admin UI does not expose it. This is the correct approach and no further action is needed.

---

Strengths

• Consistent structure across both guides (prerequisites → auth setup → bot token → admin console → trigger → troubleshoot)
• Troubleshooting tables cover common failure modes with actionable checks
• Security note that the admin PAT is used once for automatic webhook setup and immediately discarded is a strong trust signal for security-conscious admins
• <Warning> callouts correctly pre-empt the two most common config mistakes: https:// in the Bitbucket domain field, and missing https:// in the Jira Base URL
• The Jira guide correctly scopes setup responsibilities: global config in Admin Console, per-user account linking in Settings

---

This review was generated by an AI agent (OpenHands) on behalf of the user through OpenHands Automation. View conversation

[all-hands-bot]

🟡 Suggestion: The Repository: line format is documented as Repository: Acme/web-app, but it is not specified which SCM provider this org/repo slug refers to. Enterprise installations may have both GitHub and Bitbucket Data Center connected — it is ambiguous which one OpenHands will target. Consider adding a clarifying sentence, e.g.:

Use the same org/repo slug as your connected source control provider — for example, a GitHub repository as github-org/repo-name, or a Bitbucket Data Center project/repository as project-key/repo-slug.

This will prevent user confusion when multiple SCM providers are configured.