Configure: expose each tool's configurable metadata as a collapsible form on its card in the Tools tab

[sandesh-sp]

Motivation

There is no way to set a tool/plugin's metadata from the admin Configure page. To change what a tool is configured with today, an admin has to download the mission's configuration JSON, hand-edit it, and re-upload it — or edit the tool's default metadata in source and rebuild. Neither path tells them what the configuration is currently set to, which keys exist, or what values each key accepts.

That guesswork is the main friction when adding a plugin or assembling a dashboard: you set something, upload, reload, and find out from the running map whether you got it right. It is slow, error-prone, and it puts a code-level task in front of a non-coding admin — exactly the audience the Configure page exists for.

How it should work

Every tool card in the Configure page's Tools tab carries its own Configuration section, collapsed by default. Most of the time the metadata is prefilled from the tool's defaults and needs no change, so the section stays out of the way — the tab still reads as a grid of tool cards at a glance.

Expanding it reveals a generated form: one labeled control per configurable field the tool declares, with its description shown inline and its input type matching the field (checkbox, dropdown of the accepted values, number, text, color, and so on). Fields prefill from the tool's declared defaults, so an admin can see at a glance what the tool is currently set to and what values it will accept, without opening a JSON file.

Changing a control edits the mission configuration in place, exactly like every other Configure edit — the change is staged and lands when the admin saves the configuration. No download, no upload, no rebuild.

Tools that declare no configurable metadata say so plainly in their collapsed section rather than showing an empty form.

Done when

• Each tool card in the Tools tab has a Configuration section that is collapsed on first render and can be expanded and collapsed independently of other cards.
• Expanding a tool that declares configurable fields shows a form with one labeled control per field, its description visible, and an input type appropriate to that field — dropdown fields list only the accepted values.
• Controls prefill from the tool's declared defaults when the mission configuration has not set a value.
• Editing a control and saving the configuration persists the value; reloading the Configure page shows the saved value in the same control.
• Editing a tool's configuration when that tool has not yet been turned on for the mission writes the value onto that tool, not anywhere else in the configuration.
• A tool that declares no configurable fields shows a clear "no further configuration" message instead of an empty form.
• Turning a tool on/off and setting its icon still work from the Tools tab.
• A handful of tools that currently declare no configurable metadata get their declarations authored so their sections render real forms — at minimum the ones exercised while building a modern-interface dashboard.

Out of scope

• Backfilling metadata declarations for every tool. Only the few tools called out above. The rest get declarations as they are needed; the form renders whatever a tool declares.
• A raw JSON escape hatch. If a tool has a setting it does not declare, the fix is to declare it — not to hand the admin a JSON editor.
• Marking inherited-vs-overridden values, or per-field "reset to default." Fields prefill from defaults and write through on save; distinguishing "set" from "inherited" is a later refinement.
• The Components tab. Same shape of problem, separate issue.
• Panel placement and layout configuration. Handled elsewhere in the Configure page.

Draft implementation plan — written as of e13a073 on 2026-09-04. Rough guide; re-verify against latest code.

Current behavior

• configure/src/components/Tabs/Tools/Tools.js renders the Tools tab as a fixed-height (300px) MUI Grid of cards, one per entry in the toolConfiguration store slice, plus a static "Custom Tools" info card. Clicking a card dispatches a tool modal.
• configure/src/components/Tabs/Tools/Modals/ToolModal/ToolModal.js is that modal: an ON/OFF switch, an MDI icon text field, and — when the tool's config declares config.rows — a <Maker config={toolConfig.config} toolName={toolName} inlineHelp />. Otherwise it renders "This tool takes no further configurations." So the form-generation machinery already exists; this issue is largely about relocating and defaulting it.
• configure/src/core/Maker.js (~2000 lines) turns a {rows: [{components: [...]}]} metaconfig into MUI controls and writes edits back via updateToolInConfiguration. It already handles checkbox, switch, dropdown, colordropdown, slider, colorpicker, number, text, objectarray, and tabs.
• Per-tool metadata lives in src/essence/Tools/<Tool>/config.json — defaults, description, descriptionFull, defaultIcon, paths, and the optional config.rows. API/updateTools.js aggregates every tool's config.json (core plus *Plugin-Tools* / *Private-Tools* dirs) into the gitignored configure/public/toolConfigs.json, which the Tools tab fetches through calls.getToolConfig.
• Tools with no config.rows today: AddTempLayer, Chart, Chemistry, Comparison, FetchStats (empty rows), Kinds (a pseudo-tool the tab skips).
• Defaults are handled inconsistently: ToolModal's handleClose walks the rows and back-fills defaults into the configuration on close, which is why prefilling currently depends on having opened and closed the modal.

Where the change lands & rough plan

1. In Tools.js, give each card a collapsible section (MUI Accordion or Collapse) holding the same <Maker> invocation the modal uses. The card's fixed 300px height and its whole-card onClick → modal will both need rework so expanding doesn't fight the grid layout or re-trigger the modal.
2. Decide the modal's fate — either retire ToolModal in favor of the inline section, or keep it as the "expanded" view. If it is retired, its default-backfill logic in handleClose needs a home (see gotcha).
3. Move default prefilling out of a close handler and into the render/expand path so a field shows its declared default without the admin having to open and close anything.
4. Author config.rows for the chosen few tools in their src/essence/Tools/<Tool>/config.json. Follow Legend/config.json as the model — field paths under variables., plus name, description, type, width, and options/defaultChecked/default. Draw/config.json (16 fields) is the richest example.
5. toolConfigs.json is generated and gitignored, so a config.json edit only shows up after API/updateTools.js re-runs — dev startup does this; a stale file looks exactly like "my field didn't render."

⚠️ Gotcha: Maker's updateConfiguration looks the tool up with getToolFromConfiguration, which searches configuration.tools by name. A tool that has never been turned on for the mission is absent from that array, so tool is null and the update falls through to the final else branch — writing the field path (e.g. variables.foo) onto the root of the mission configuration instead of onto the tool. The modal papers over this by pushing a tool entry when the ON switch or icon field is touched first; an always-visible inline form removes that accident of ordering and will hit the bug directly. Ensure the tool entry exists before the first field write.

References

• configure/src/components/Tabs/Tools/Tools.js
• configure/src/components/Tabs/Tools/Modals/ToolModal/ToolModal.js
• configure/src/core/Maker.js (entry point at the bottom of the file)
• configure/src/core/utils.js — getToolFromConfiguration, updateToolInConfiguration, getIn, setIn
• API/updateTools.js — builds configure/public/toolConfigs.json
• src/essence/Tools/Legend/config.json, src/essence/Tools/Draw/config.json — metaconfig examples
• configure/src/components/Tabs/Components/ — the parallel Components tab, out of scope but the same pattern

[sandesh-sp]

Follow-up from investigating this: the gap is wider than the issue body describes, and the more painful half is not the tool's own options.

The form machinery for a tool's declared options already exists — the Tools tab's modal renders whatever a tool declares and writes it into the mission configuration. What has no admin UI at all is a tool's metadata block: requiredOrientation, compatiblePositions, preferredPosition, modernLayoutSupport, startHidden, startUnloaded, width, height, icon.

That block is what decides where a tool is allowed to live in a modern dashboard, and the modern runtime reads it only from the mission configuration's tool entry — never from the tool's own manifest. So:

• A mission created through the Configure page carries no metadata on any tool. Those tools end up with no placement constraints at all and pile into whichever compatible panel comes first by priority.
• The only way to fix that today is to download the mission JSON, hand-write a metadata block onto each tool entry, and re-upload — exactly the download/edit/upload loop this issue is about.
• The committed demo mission works only because each of its tool entries carries a hand-copied metadata block.

So the collapsible Configuration section should cover both: the tool's own declared options and its metadata block, the latter rendered from a schema shared by every tool (dropdown of the valid orientations, multi-select of the valid panel positions, and so on) and prefilled from what the tool declares.

Two notes for whoever picks this up:

• Placement metadata can veto an explicit placement. Naming a tool in a panel's tool list is not enough — the tool's compatiblePositions and requiredOrientation are still checked, and an incompatible tool is skipped with only a console warning. An admin editing these fields can therefore make a tool silently vanish from a panel it is explicitly assigned to.
• Bad values are not reported. A misspelled position is not rejected; it is replaced with a default, so the tool ends up somewhere the admin never chose. Worth surfacing accepted values in the form rather than relying on free text.

The metadata schema itself has structural problems that this issue should not try to fix — duplicated fields, fields that are stored and validated but never read, and no merge between what a tool declares and what a mission overrides. Filing that separately.

[sandesh-sp]

The metadata schema work is now filed as #397 — merging a tool's declared metadata with per-mission overrides, and pruning/restructuring the schema itself. The two should agree on the field list; #397 should land first or alongside, since it decides what this issue's form renders.