NIFI-15439: Ensure that Process Groups are accessible from the approp…

[markap14]

…riate endpoint but not accessible elsewhere

Summary

NIFI-00000

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-00000
• Pull Request commit message starts with Apache NiFi Jira issue number, as such NIFI-00000
• 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

Licensing

• 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

• Documentation formatting appears as expected in rendered files

[mcgilman]

Will review...

[mcgilman]

Thanks for the PR @markap14! Noted one question below and I'm seeing a few instances of the existing getGroup(string) which I'm wondering if we want migrated to get(string, null) to prevent Connector managed Process Groups being returned.

• FlowDifferenceFilters
• FlowAnalyzingRegistryClientNode
• FlowAnalyzingRegistryClientNodeTest

Noted that TestStandardControllerServiceProvider, TestStandardProcessScheduler, TestStandardRemoteProcessGroupDAO, and StandardControllerServiceResolverTest still use getGroup(string) but I think these make sense.

[mcgilman]

Do we care about losing the uiOnly capability for clients using this?

[markap14]

Nah, this was a mistake because the parameter is available in the Resource. But we don't expose it in other endpoints so we shouldn't expose it here.

[markap14]

Thanks @mcgilman I think for those cases, calling getFlow with or without the Connector ID argument is probably OK because they are requesting specific ID's that they've obtained from other groups, so they won't ever request a Group unless it was handed the group from a Connector. But I think it probably makes sense to explicitly use null from FlowAnalyzingRegistryClient because that should never be used in relation to a Connector. But it would potentially make sense to use FlowDifferenceFilters to check if a Connector's flow has changed, so let's leave it without the explicit null.