DOCS-13: Custom entity panel content - #361
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:
WalkthroughThe graph definition guide now documents extension-defined custom Entity panel accordion sections through optional ChangesGraph definition info documentation
Estimated code review effort: 2 (Simple) | ~10 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
|
@coderabbitai review |
✅ Action performedReview finished.
|
| | `info` key | Required | Stable section identifier. Must match `^[a-z0-9_-]{1,128}$`, which allows lowercase letters, numbers, hyphens, and underscores. | | ||
| | `title` | Required | Section title shown in the Entity panel accordion. | | ||
| | `position` | Required | Integer that controls section order. Lower values render first. Use `1` or greater. | | ||
| | `markdown.content` | Required | Markdown content rendered in the section body. | |
There was a problem hiding this comment.
Are there constraints we want to document right now or a flavor of markdown we're supporting?
| - The `tag` namespace prefix is reserved in any letter case, including `tag`, `Tag`, and `TAG`. Do not use this prefix in an extension definition schema. If you do, BloodHound rejects the upload. | ||
| </Warning> | ||
|
|
||
| ## Custom Entity panel content |
There was a problem hiding this comment.
We should be consistent with casing here, and throughout. I think Entity Panel is more correct, but open to suggestions.
For this specific case, either:
- Custom Entity Panel content
- Custom Entity Panel Content
- Custom entity panel content
There was a problem hiding this comment.
I'll normalize based on option 1.
|
|
||
| ## Custom Entity panel content | ||
|
|
||
| Use the `info` object to define custom Entity panel sections for node kinds and relationship kinds. When a user selects a node or relationship in Explore, BloodHound renders matching `info` entries as accordion sections in the Entity panel. |
There was a problem hiding this comment.
matching
infoentries
is a little confusing.
might be more clear to say:
When ... selects ..., BloodHound renders an Entity Panel with the specified accordion sections as defined by the
infoentries.
| | Field | Requirement | Description | | ||
| | --- | --- | --- | | ||
| | `info` key | Required | Stable section identifier. Must match `^[a-z0-9_-]{1,128}$`, which allows lowercase letters, numbers, hyphens, and underscores. | | ||
| | `title` | Required | Section title shown in the Entity panel accordion. | |
There was a problem hiding this comment.
We should clarify that it's the title displayed in the header of the accordion, not within the contents themselves.
in the ... accordion
is ambiguous.
| | `position` | Required | Integer that controls section order. Lower values render first. Use `1` or greater. | | ||
| | `markdown.content` | Required | Markdown content rendered in the section body. | | ||
|
|
||
| For a single kind, BloodHound orders sections by `position`. If a node has multiple kinds and more than one kind defines `info` entries, BloodHound orders the sections by `position`, then `title`, and then the contributing node kind. Relationship panels use the same ordering behavior with the contributing relationship kind as the final tiebreaker. |
There was a problem hiding this comment.
We're not supporting multi-kind yet. That's an idea we had, but we're sticking to just the primary kind to start for simplicity's sake.
|
|
||
| For a single kind, BloodHound orders sections by `position`. If a node has multiple kinds and more than one kind defines `info` entries, BloodHound orders the sections by `position`, then `title`, and then the contributing node kind. Relationship panels use the same ordering behavior with the contributing relationship kind as the final tiebreaker. | ||
|
|
||
| If no `info` entries are defined for the selected kind, BloodHound does not render extension-defined Entity panel sections. |
There was a problem hiding this comment.
We should make it clear that all entity panels start with Object Information sections at the top (position 0) and lists all of a node's/edge's property, as it currently does. If info is omitted, this is still shown, there just isn't any additional panels.
Purpose
This pull request (PR) documents an OpenGraph enhancement for v9.5.0.
Developers can use a new
infoobject in the extension definition schema to control how content renders in the Entity panel for node and relationship kinds.Note
This PR intends to add reference content only. I plan to add it to the draft extension development tutorial (#351) to showcase how this influences UI behavior).
Summary by CodeRabbit