NIFI-16240 - Navigate to the referenced parameter from property table Go to Parameter

[rfellows]

NIFI-16240 Navigate to the referenced parameter from a component property's "Go to Parameter"

Summary

JIRA: NIFI-16240

When a Processor or Controller Service property value contains a parameter reference (for example #{kafka.brokers}), the property table offers a Go to Parameter menu item. Selecting it navigated to the bound Parameter Context's edit dialog but gave no indication of which parameter the user came from — they landed on an unfiltered parameter table and had to find the row themselves. In contexts with dozens of parameters this defeats the purpose of the link, and PropertyTable.canGoToParameter carried a long-standing TODO acknowledging that the route could not target a specific parameter.

This change extracts the referenced parameter name from the property value and passes it along with the navigation, so the Parameter Context listing selects and scrolls to the matching row on arrival. The receiving side already understands this — the parameter table's highlightedParameterName input and the listing's reading of Router navigation state were added in NIFI-16217 — so this change is limited to producing the value at the origin and preserving it across the save-before-leave flow.

How it works

extractParameterName (new, apps/nifi/src/app/ui/common/utils/parameter.utils.ts) parses the first #{...} reference from a property value, supporting unquoted, single-quoted, and double-quoted names (#{name}, #{'name'}, #{"name"}). It returns undefined when no reference is present or the reference is empty, in which case navigation proceeds exactly as before with no highlight. When a value contains multiple references (#{p1}-#{p2}), the first in reading order wins — deterministic and non-surprising, and a natural place to later offer a sub-menu listing every referenced parameter.

The extracted name is wrapped in the existing PostUpdateNavigationState shape ({ highlightedParameterName }) and spread into the Angular Router's navigation state alongside the backNavigation entry the dialogs already send. For a dirty form, the state has to survive the "Save changes before going to this Parameter?" round trip, so it is threaded through the update request/response types and re-applied when the post-update navigation is finally performed:

flowchart TD
    A["Property table: Go to Parameter\n(value contains #{param})"] --> B["effects goToParameter(parameterValue)"]
    B --> C["extractParameterName(value)"]
    C -->|no reference| N0["navigate without highlight\n(existing behavior)"]
    C -->|"name"| D{"Edit form dirty?"}

    D -->|"No"| E["router.navigate(commands,\nstate: { backNavigation, highlightedParameterName })"]

    D -->|"Yes"| F["YesNoDialog:\nSave changes before going to this Parameter?"]
    F -->|"No"| E
    F -->|"Yes"| G["submitForm(commands, commandBoundary,\npostUpdateNavigationState)"]
    G --> H["update Processor / Controller Service request\ncarries postUpdateNavigationState"]
    H --> I["update success response\ncarries postUpdateNavigationState"]
    I --> E

    E --> J["ParameterContextListing reads\nlastSuccessfulNavigation().extras.state"]
    J --> K["EditParameterContext passes\n[highlightedParameterName] to parameter-table"]
    K --> L["Matching row selected and scrolled into view"]

Loading

Scope and limitations

Inherited parameters navigate to the process group's bound Parameter Context and highlight the row there. Inherited rows are already rendered in that context's parameter table, so the highlight lands correctly; this change intentionally does not walk the inheritance chain to open the ancestor context that defines the parameter.

What changed

Flow designer / Controller Services effects

• flow.effects.ts and controller-services.effects.ts: the goToParameter callback now receives the property value, extracts the parameter name, and passes an optional PostUpdateNavigationState into the shared goTo helper. goTo spreads that state into router.navigate for both the clean-form and "don't save" paths, and forwards it to submitForm on the "save" path.
• The post-update navigation performed on updateProcessorSuccess / configure-success now spreads postUpdateNavigationState into the navigation state.

Types

• UpdateProcessorRequest, UpdateProcessorResponse, UpdateControllerServiceRequest, ConfigureControllerServiceRequest, and ConfigureControllerServiceSuccess gain an optional postUpdateNavigationState?: PostUpdateNavigationState.

Dialogs

• EditProcessor.submitForm and EditControllerService.submitForm accept an optional third argument, postUpdateNavigationState, and include it in the emitted update request.

Cleanup

• Removed the obsolete TODO in PropertyTable.canGoToParameter stating that the parameter context route cannot target a specific parameter.

New file

• apps/nifi/src/app/ui/common/utils/parameter.utils.ts (+ spec).

No backend, REST, or persistence changes; no new user-facing strings.

Manual verification

1. Create a Parameter Context with several parameters (enough that the table scrolls) and bind it to a process group.
2. Add a Processor, set a property value to #{some-param}, and apply.
3. Reopen the Processor, use the property's context menu → Go to Parameter. The Parameter Context dialog opens with some-param selected and scrolled into view.
4. Repeat with a dirty form: change another property first, then choose Go to Parameter.
   • Answer Yes to the save prompt — the update is applied and the destination still highlights some-param.
   • Answer No — navigation happens immediately and still highlights some-param.
   • Cancel — the dialog stays open, unchanged.
5. Repeat steps 2–4 for a Controller Service property.
6. Try quoted forms (#{'param with spaces'}, #{"param with spaces"}) and a value that embeds a reference (prefix #{some-param} suffix).
7. Regression: a property whose value contains no parameter reference offers no Go to Parameter item; a value referencing a name that does not exist in the context navigates normally with no row selected.
8. Regression: verify the back-navigation breadcrumb from the Parameter Context dialog still returns to the originating Processor / Controller Service edit dialog.
9. Inherited parameters: reference a parameter inherited from another context and confirm navigation lands on the bound context with the inherited row highlighted.

[scottyaslan]

Reviewing...

[scottyaslan]

extractParameterName should share a capturing form of the same charset as PropertyTable.PARAM_REF_REGEX (/#{(['"]?)[a-zA-Z0-9-_. ]+\1}/), and trim the captured name.

canGoToParameter uses the strict regex; this uses [^}]+. For a value like #{bad:name} #{kafka.brokers}, the menu appears because of kafka.brokers, but extract returns bad:name and no row is selected.

Unquoted #{ my-param } also matches (space is in the charset) and extracts ' my-param '. Highlight is an exact === on parameter.name, so the row is missed. #{} / #{ } should still return undefined.

Suggested:

const match = /#{(['"]?)([a-zA-Z0-9-_. ]+)\1}/.exec(value);
return match?.[2]?.trim() || undefined;

Exporting that regex (and using it from PropertyTable) would keep the two from drifting. Please also add specs for mixed invalid-then-valid refs (#{bad:name} #{kafka.brokers} → kafka.brokers) and #{ my-param } / #{ }.