BP-2693: Release notes (2026-06-16)#312
Conversation
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
WalkthroughThis PR updates OpenGraph node schema validation to allow empty ChangesOpenGraph schema relaxation
Release notes for 2026-06-16
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes Possibly related PRs
Suggested labels
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
@coderabbitai review |
✅ Action performedReview finished.
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (3)
docs/opengraph/developer/nodes.mdx (2)
18-18: 🛠️ Refactor suggestion | 🟠 Major | ⚡ Quick winUpdate user-facing documentation to reflect the relaxed schema constraint.
Lines 18 and 22 state that nodes require a
kindsarray without specifying that it can now be empty. Line 51 describeskindsas required (which remains true) but doesn't clarify that the array can be empty per the updated schema.The embedded schema on line 192 now permits
minItems: 0, allowing emptykindsarrays. The user-facing documentation should explicitly state whether empty arrays are valid, and if so, when they should be used.📝 Suggested clarification
Consider adding a note after line 52:
<ResponseField name="kinds" type="array" required> An array of strings that classify the node. You can include up to three kinds per node. The first value is the primary kind, which controls the node styling in the graph. + + <Note> + While the `kinds` array is required, it may be empty. However, nodes with empty `kinds` arrays cannot participate in structured graphs or be matched in Cypher queries by kind label. + </Note>Also applies to: 22-22, 51-52
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/opengraph/developer/nodes.mdx` at line 18, Update the user-facing text in docs/opengraph/developer/nodes.mdx to clarify that the node property "kinds" is required but may be an empty array per the updated schema (see embedded schema permitting minItems: 0); explicitly state that empty "kinds" arrays are valid and add a short guidance sentence describing when to use an empty array (e.g., for nodes without categorical kinds or when kinds are intentionally unspecified) so readers understand both the requirement and the allowed empty state for "kinds".
54-54:⚠️ Potential issue | 🟠 MajorClarify semantics for nodes with an empty
kindsarray (minItems: 0) in Cypher and structured graphs
nodes.mdxsayskindsvalues are used as Cypher labels (MATCH (n:Okta_User ...)) and that a node participates in a structured graph only if at least onekindsvalue matches an installednode_kinds.name. However, thekindsschema permits empty arrays (minItems: 0, whilekindsis still required), andopengraph-node.jsonmirrors the same constraint.Document what should happen when
kinds: [], specifically:
- Whether such nodes are ingested with no Neo4j labels (and therefore cannot be matched via
MATCH (n:<kind>)).- Whether they are excluded from structured-graph capabilities (pathfinding/findings/metrics/etc.).
- What the graph UI does for the “primary kind”/icon when there is no first
kindselement.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/opengraph/developer/nodes.mdx` at line 54, Clarify the semantics for nodes with an empty kinds array by updating the nodes.mdx documentation and schema notes: state that when kinds: [] the node is ingested without any Neo4j labels (so MATCH (n:<kind>) cannot match it), that it is not considered to participate in structured-graph features tied to node_kinds.name (so pathfinding/findings/metrics that rely on kind membership will exclude it), and that the graph UI should fall back to a generic/unknown primary kind/icon when there is no first kinds element; reference the kinds property, the node_kinds.name matching rule, and opengraph-node.json so consumers and implementers know the expected behavior and fallback.docs/assets/opengraph/opengraph-node.json (1)
3-3:⚠️ Potential issue | 🟠 MajorFix
kindsdocumentation/schema mismatch and clarify primary-kind/icon behavior for empty arrays.In
docs/assets/opengraph/opengraph-node.json, line 3 says each node has “at least one kind…”, but thekindsschema sets"minItems": 0(lines 37-42), allowing an emptykindsarray. Thekindsdescription (line 42) assumes a first element exists for “primary kind”/icon selection; either document the intended fallback behavior for empty arrays (or explicitly tie it tometadata.source_kindappending) or change the constraint tominItems: 1. The examples (lines 46-71) only show non-emptykinds; add an example for the empty-array case if it’s intended to be supported.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/assets/opengraph/opengraph-node.json` at line 3, The docs/schema mismatch: either require at least one kind or document fallback behavior when kinds is empty; update docs/assets/opengraph/opengraph-node.json so the schema and description align by either (A) set "kinds" array to "minItems": 1 and update the description to assert a primary kind is always present, or (B) keep "minItems": 0 but revise the "kinds" description to state what happens when the array is empty (e.g., primary kind/icon selection falls back to metadata.source_kind or a default) and add an example showing an empty "kinds": [] case; ensure references to metadata.source_kind are explicit if used as the fallback.
🧹 Nitpick comments (1)
docs/assets/opengraph/opengraph-node.json (1)
46-71: ⚡ Quick winAdd an example demonstrating empty
kindsarray.All three examples show non-empty
kindsarrays. Since the schema now allowsminItems: 0, consider adding an example that demonstrates a valid node with an emptykindsarray to clarify when and how this constraint should be used.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/assets/opengraph/opengraph-node.json` around lines 46 - 71, Add a new example object in the "examples" array showing a valid node with an empty "kinds" array (e.g., an entry with a unique "id" like "node-empty-kinds" and a minimal "properties" object such as {"environmentid":"my-environment-001","collected":false}) to demonstrate the schema's allowance of minItems: 0 for the "kinds" field; ensure the object follows the same shape as the other examples (includes "id", optional "properties", and an explicit "kinds": []) so readers can see a correct empty-case usage.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@docs/resources/release-notes/2026-06-16.mdx`:
- Line 88: The markdown link target for "Object interaction" is malformed with
double slashes ("/analyze-data//explore/search#object-interaction"); locate the
link text "Object interaction" in the release notes and fix the href to remove
the extra slash so it reads "/analyze-data/explore/search#object-interaction" to
restore proper navigation.
In `@docs/resources/release-notes/summary.mdx`:
- Line 45: The table row link currently points to the wrong anchor
"`#incremental-edge-updates`"; update the link target in the Post-Processing table
cell (the markdown line containing "[Analysis Performance
Improvements](/resources/release-notes/2026-06-16#incremental-edge-updates)") to
use the actual heading anchor "`#analysis-performance-improvements`" so it matches
the "Analysis Performance Improvements" heading in the 2026-06-16 release notes.
---
Outside diff comments:
In `@docs/assets/opengraph/opengraph-node.json`:
- Line 3: The docs/schema mismatch: either require at least one kind or document
fallback behavior when kinds is empty; update
docs/assets/opengraph/opengraph-node.json so the schema and description align by
either (A) set "kinds" array to "minItems": 1 and update the description to
assert a primary kind is always present, or (B) keep "minItems": 0 but revise
the "kinds" description to state what happens when the array is empty (e.g.,
primary kind/icon selection falls back to metadata.source_kind or a default) and
add an example showing an empty "kinds": [] case; ensure references to
metadata.source_kind are explicit if used as the fallback.
In `@docs/opengraph/developer/nodes.mdx`:
- Line 18: Update the user-facing text in docs/opengraph/developer/nodes.mdx to
clarify that the node property "kinds" is required but may be an empty array per
the updated schema (see embedded schema permitting minItems: 0); explicitly
state that empty "kinds" arrays are valid and add a short guidance sentence
describing when to use an empty array (e.g., for nodes without categorical kinds
or when kinds are intentionally unspecified) so readers understand both the
requirement and the allowed empty state for "kinds".
- Line 54: Clarify the semantics for nodes with an empty kinds array by updating
the nodes.mdx documentation and schema notes: state that when kinds: [] the node
is ingested without any Neo4j labels (so MATCH (n:<kind>) cannot match it), that
it is not considered to participate in structured-graph features tied to
node_kinds.name (so pathfinding/findings/metrics that rely on kind membership
will exclude it), and that the graph UI should fall back to a generic/unknown
primary kind/icon when there is no first kinds element; reference the kinds
property, the node_kinds.name matching rule, and opengraph-node.json so
consumers and implementers know the expected behavior and fallback.
---
Nitpick comments:
In `@docs/assets/opengraph/opengraph-node.json`:
- Around line 46-71: Add a new example object in the "examples" array showing a
valid node with an empty "kinds" array (e.g., an entry with a unique "id" like
"node-empty-kinds" and a minimal "properties" object such as
{"environmentid":"my-environment-001","collected":false}) to demonstrate the
schema's allowance of minItems: 0 for the "kinds" field; ensure the object
follows the same shape as the other examples (includes "id", optional
"properties", and an explicit "kinds": []) so readers can see a correct
empty-case usage.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: a32bc5bf-3fba-4d46-a4f4-1c400eb9c94a
📒 Files selected for processing (6)
docs/assets/opengraph/opengraph-node.jsondocs/docs.jsondocs/opengraph/developer/nodes.mdxdocs/resources/release-notes/2026-05-28.mdxdocs/resources/release-notes/2026-06-16.mdxdocs/resources/release-notes/summary.mdx
💤 Files with no reviewable changes (1)
- docs/resources/release-notes/2026-05-28.mdx
|
|
||
| <Update label="OpenHound" description="New Feature" tags={["Data Collection"]}> | ||
| {/*BED-8357*/} | ||
| ## GitHub Enterprise SSO Support |
There was a problem hiding this comment.
Based on my reading of BED-8357, this adds new autogenerated reference docs for GitHub nodes and edges. I haven't run through that process before, but would be happy to do so if someone can show me.
What's less clear is whether this impacts any of the manually maintained configuration docs. Can you please confirm?
| | Accessibility | [Accessibility Improvements](/resources/release-notes/2026-06-16#accessibility-improvements) | Navigate data tables more effectively with improved headers, sorting behavior, keyboard support, and screen reader announcements. | | ||
| | API | [OpenGraph Extension Namespace Visibility](/resources/release-notes/2026-06-16#opengraph-extension-namespace-visibility) | View each extension's namespace in the OpenGraph extension information API response. | | ||
| | Explore | [Full-Path Highlighting](/resources/release-notes/2026-06-16#full-path-highlighting) | Highlight the full path through a selected node so you can better isolate how it participates in longer Attack Paths. | | ||
| | OpenGraph (Enterprise) | [Pre-Installed SpecterOps Extensions](/resources/release-notes/2026-06-16#pre-installed-specterops-extensions) | Use supported GitHub, Jamf, and Okta OpenGraph extensions without a separate installation step. | |
There was a problem hiding this comment.
BloodHound Enterprise (not opengraph enterprise) this is a function in the SaaS app
There was a problem hiding this comment.
That's the pattern we're using on the summary page when an update applies to BloodHound Enterprise only. There's not enough room for the image like on the detailed release notes page.
See the Posture and Zone Builder updates on the lines below this. I can add clarification in the description, but otherwise we break the pattern.
| | Accessibility | [Accessibility Improvements](/resources/release-notes/2026-06-16#accessibility-improvements) | Navigate data tables more effectively with improved headers, sorting behavior, keyboard support, and screen reader announcements. | | ||
| | API | [OpenGraph Extension Namespace Visibility](/resources/release-notes/2026-06-16#opengraph-extension-namespace-visibility) | View each extension's namespace in the OpenGraph extension information API response. | | ||
| | Explore | [Full-Path Highlighting](/resources/release-notes/2026-06-16#full-path-highlighting) | Highlight the full path through a selected node so you can better isolate how it participates in longer Attack Paths. | | ||
| | OpenGraph (Enterprise) | [Pre-Installed SpecterOps Extensions](/resources/release-notes/2026-06-16#pre-installed-specterops-extensions) | Use supported GitHub, Jamf, and Okta OpenGraph extensions in BloodHound Enterprise without a separate installation step. | |
There was a problem hiding this comment.
Update to BloodHound Enterprise OpenGraph
2 participants
Purpose
This pull request (PR) adds release notes for the June 16, 2026 release to the release integration branch, which includes:
No release for:
There are several related PRs for supporting documentation that also need to be reviewed and merged separately to ensure cross references from release notes are reliable:
Staging
Summary by CodeRabbit
Documentation
Chores