NIFI-16229 - Fixed inherited asset Parameter Context updates

[skeossei]

Preserve inherited Parameter classification during repeated effective Parameter enrichment so clustered updates continue to accept assets owned by the source context.

Summary

NIFI-16229

Parameter Context updates calculate changes to effective Parameters before applying them. In a cluster, an enriched update is replicated to the nodes and processed again. The existing classification inferred that a Parameter was inherited when it was absent from the incoming DTO. After the first enrichment added the inherited Parameter to the DTO, the second pass incorrectly classified it as local.

This change determines inheritance from the effective Parameter's source context instead. A Parameter is inherited when its source Parameter Context differs from the Parameter Context being updated. This preserves the classification across repeated enrichment while retaining the existing handling for effective Parameter removals.

The regression test updates an existing child Parameter Context to inherit a parent containing an asset-backed Parameter. It verifies the local and effective views, then resubmits the effective DTO to exercise repeated enrichment. The same test runs in standalone and clustered configurations. Existing tests confirm that removing an inherited asset context remains supported and that a local Parameter still cannot reference an Asset owned by another context.

Tracking

Please complete the following tracking steps prior to pull request creation.

Issue Tracking

• Apache NiFi Jira issue created

Pull Request Tracking

• Pull Request title starts with Apache NiFi Jira issue number, such as NIFI-16229
• Pull Request commit message starts with Apache NiFi Jira issue number, as such NIFI-16229
• Pull request contains commits signed with a registered key indicating Verified status

Pull Request Formatting

• Pull Request based on current revision of the main branch
• Pull Request refers to a feature branch with one commit containing changes

Verification

Please indicate the verification steps performed prior to pull request creation.

Build

• Build completed using ./mvnw clean install -P contrib-check
  • JDK 21
  • JDK 25

Targeted verification completed using JDK 21:

• StandardNiFiServiceFacadeTest
• ParameterContextIT#testAddInheritedContextWithAssetReference
• ClusteredParameterContextIT#testAddInheritedContextWithAssetReference
• ClusteredParameterContextIT#testRemoveInheritedContextWithAssetReference
• ClusteredParameterContextIT#testAssetReferenceFromDifferentContext

Licensing

• No new dependencies introduced
• New dependencies are compatible with the Apache License 2.0 according to the License Policy
• New dependencies are documented in applicable LICENSE and NOTICE files

Documentation

• No documentation changes required
• Documentation formatting appears as expected in rendered files

[ncover21]

I think the diagnosis is right and moving the classification onto the source context lines up with what StandardParameterContext.getEffectiveParameterUpdates already does.

One concern though. I think this regresses deleting a local parameter that overrides a same named inherited one.

Walking it with a child context that locally overrides the parent's shared:

1. Client submits the deletion, a ParameterDTO named shared with description/sensitive/value/referencedAssets all null, so StandardParameterContextDAO.getParameters treats it as a deletion.
2. getProposedParameters removes the local copy, then the merge re-supplies shared from the parent, so the effective value doesnt actually disappear.
3. Parameter.equals compares parameterContextId, so shared always lands in proposedParameterUpdates, carrying the parent's Parameter and the parent's id.
4. parameterEntities contains shared because the client submitted it, so the loop reuses the client's original deletion entity and stamps inherited=true onto it.
5. On apply, getParameters skips anything with inherited == true, so the map never gets the null value that means "delete this one", and updateParameters only walks the delta map, so shared is left untouched.

Net effect is the update request reports success but the local override is still there. The old predicate returned false here because the name was present in the incoming DTO, so this case worked before.

I dont think its cluster only either, ParameterUpdateManager.performParameterContextUpdate applies the same mutated DTO on the standalone path. And it looks reachable from the UI, once an override is saved DtoFactory reports it as inherited=false, so canDelete takes the normal path and sends just the name.

There is a second case I'm less sure about but wanted to flag while I'm here: a same context value reference like Y = #{X}. If you update only X, then Y lands in the effective updates with its resolved value and a parameterContextId equal to this context, so the new predicate calls it local and it gets persisted with the resolved literal, or with ******** if Y is sensitive. Before, Y was marked inherited because it wasnt in the DTO, so it was skipped on apply.

What I think might work is keying off what the client actually submitted rather than the source context