Overview
Scripting properties let administrators supply custom JavaScript templates and data objects that the board evaluates at render time. The primary use case is customising how capacity tooltips, column labels, and per-plan data appear on the board.Property Reference
columnTooltipTemplate
Controls the HTML rendered inside capacity tooltips on Plan columns. Accepts either a static string template or a JavaScript function that receives the column and row objects and returns an HTML string.
When
columnTooltipTemplate is not configured, the board falls back to the default tooltip format, which shows aggregate capacity metrics:
When
columnTooltipTemplate is configured, the template receives column and row objects and can render per-user allocation breakdowns. The rendered HTML is stored on the .capacityLoad element’s data-html attribute and displayed by the tooltip engine.
Per-user allocation format (custom template)
A custom template can expose the following data per team member:
Configuration example — function form
After programmatically changing
columnTooltipTemplate, call setCurrentView() to trigger a re-render. Without this call, the board continues showing the previous tooltip template.scriptData
Stores arbitrary custom data per plan in the scheduler configuration. This data is attached to each plan’s
userData object and is available inside columnTooltipTemplate functions and other custom rendering logic via column.scriptData.
The server-side capacity helper (ColumnDataScriptHelper) populates scriptData with capacity metrics for each plan. The board configuration is embedded server-side — not delivered via XHR — so scriptData values are available immediately when the board initialises.
Fields populated by the capacity helper
userCapacities entry structure
Users without a team calendar entry for a plan’s date range receive
totalCapacity: 0.0. This means availableCapacity will equal -allocatedCapacity (always negative) for those users, which may trigger the overallocation indicator even when total capacity is simply unknown. Verify team calendar coverage when unexpected overallocation warnings appear.setCurrentView()
A method on the scheduler/board instance that refreshes the current view. Must be called after programmatically updating
columnTooltipTemplate or other view configuration properties to trigger a re-render. Without calling setCurrentView(), the board continues to display stale rendered output.
Related Configuration Properties
Scripting properties interact closely with capacity configuration. See the following references for the capacity properties that drive the data available inscriptData:
- Capacity Properties —
nextedy.gantt.calendarHolder,nextedy.gantt.useTeamCapacityModifiers,nextedy.gantt.capacityModifierAField, and related settings - Capacity Parameters — widget-level capacity parameters (
capacityLoad,userCapacityLoad,multiCapacityLoad,hoursPerDay)
- Scripting API — overview of the scripting API
- Config Script API — configuration script API reference
- Data Script API — data script API reference
Configuration Example
The following example shows a board configuration that usesscriptData and a custom columnTooltipTemplate together to render a per-user capacity tooltip with overallocation highlighting.
setCurrentView() on the board instance to trigger a re-render.
Limitations
The scripting properties documented here (
columnTooltipTemplate, scriptData) are confirmed by test evidence (capacityTooltipRendering.cy.ts, capacityHelperData.cy.ts). The full set of scriptable configuration hooks beyond tooltip rendering is not confirmed by the available source context — do not assume that other rendering phases (card content, swimlane labels, etc.) expose equivalent template hooks unless confirmed in the product.columnTooltipTemplateonly — custom scripting is confirmed for column capacity tooltips. Card-level, swimlane-level, and other rendering phases do not have confirmed equivalent scripting hooks in the available source context.- Server-side embedding —
scriptDatais populated server-side and embedded into the board configuration at render time. It is not refreshed via live XHR after initial load. - No multi-assignee capacity distribution — capacity calculations assign effort to the named assignee only; there is no distribution across multiple assignees per work item. See Capacity Properties for the full list of known capacity limitations.
- PARENT assignment mode incompatibility — the
PARENTswimlane assignment mode does not support plan normalization (planCellsMode). Scripting properties that rely on normalization data are unaffected whenplanCellsModeis disabled, but custom templates must account for the absence of normalization-derived fields when this mode is in use.
Sources
Sources
KB Articles
- Planningboard: Customizable Statistics and Capacity Indicators
- Planningboard Widget Parameters
- Troubleshooting Script Errors in Planningboard
capacityTooltipRendering.cy.tsPlanningBoardWidgetRenderer.javaviewSetup.vmcapacityHelperData.cy.tsunplanned_sidebar.js