[
https://issues.apache.org/jira/browse/NIFI-7986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17291665#comment-17291665
]
John Wise commented on NIFI-7986:
---------------------------------
We use variables specifically because they are inheritable by nested process
groups. Parameters are a non-starter for us specifically because they aren't
inheritable. Managing parameter contexts in multiple nested levels would be an
administrative nightmare for us.
> Add UI to view and update assigned parameter context for each nested process
> group.
> -----------------------------------------------------------------------------------
>
> Key: NIFI-7986
> URL: https://issues.apache.org/jira/browse/NIFI-7986
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Core UI
> Affects Versions: 1.10.0, 1.12.0, 1.11.4, 1.12.1
> Reporter: George Knaggs
> Priority: Minor
>
> Currently the assigned parameter context for a process group can only happen
> from its "Configuration" window. The scope of the parameter context only
> applies to processors and service controllers directly within that process
> group that it is assigned, excluding any nested process groups, which may
> have a different or no parameter context assigned. This is remarkably
> different than how scoping worked with variables, which had an inheritance
> model. The nature of these differences makes it important for users when
> making a copy of a flow or importing a flow from the NiFi Registry, that
> contains nested process groups, that the entire flow must be navigated and
> for each nested process group open the configure window to check and possibly
> change the assigned parameter context. The use of nested process groups had
> the advantage of keeping flows easy to read, monitor, and maintain, but now
> are a disadvantage if you want to parameterize your flows.
> This issue was also highlighted in "Better Support for Parameterizing Flows"
> under NiFi Feature Flows confluence blog. Specifically under "Import Flow"
> section:
> {code:java}
> 4. If there are nested Process Groups in the flow, the UX will need to
> provide a way to specify which Parameter Context should be used for each of
> those, since Parameter Contexts are not inherited, and because the intent of
> the original flow was to use a separate context as well. This could be done
> either by showing a hierarchy of the Process Groups and choosing a Parameter
> Context for each, or by showing a listing of Parameter Context Names that are
> referenced in the flow pulled from Registry and allowing the user to map each
> of those names to a locally defined Parameter Context.
> Note that this user experience for importing the flow addresses both of the
> key use cases: Migration of flow from dev to test to prod, as well as the
> need to create parameterized flows (i.e., import the same flow multiple times
> into the same environment, each with different parameters). Each time the
> user imports the flow, they can choose a new set of parameters to use.{code}
> I propose a change to the configuration window for a processs group, add a
> "Parameter Contexts" tab, which shows all nested process groups by name in a
> list with a scope/path/breadcrumb to help identify, and also showing its
> assigned parameter context. From here the user can check if the correct
> parameter context is assigned to the nested process groups. There could then
> be a drill in arrow ↘︎ icon for quickly drilling to the Configuration window
> for the nested process group so the user can change the assigned parameter
> context. It may not be feasible to navigate back to make additional changes,
> so alternatively, the UI could allow the change of the assigned parameter
> context from the parent process group for any nested process group.
> Added bonus, the same concept could be used within the Controller Services
> tab to show controllers services assigned to nested process groups, quickly
> identifying which controller services are disabled or invalid, which is also
> a pain when starting up flows with many nested process groups.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
