NIFI-15182: Fixed adding/removing user to multiple groups not saving…

[Freedom9339]

… to all groups.

Summary

NIFI-15182: There was an issue where if multiple groups were selected to add a user to, the update would sometimes fail on all groups, and the operation would have to be repeated to add the user to all desired groups. This also happened when deleting a user from multiple groups. This change fixes this issue.

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]

Thanks for the PR @Freedom9339! Noted a few things below.

Also, could you add some test coverage for the changed effects? The existing spec file covers loadTenants scenarios, but the effects modified in this PR (updateUserGroup$, awaitUpdateUserGroupsForCreateUser$, awaitUpdateUserGroupsForUpdateUser$, updateUserSuccess$) don't have tests yet.

In particular, a test for updateUserGroup$ verifying that multiple concurrent actions all complete their HTTP requests would help guard against regression — the original switchMap → mergeMap fix is subtle enough that it could be accidentally reverted without a test catching it.

[mcgilman]

The switchMap → mergeMap change in updateUserGroup$ correctly addresses the root cause. Thanks for catching this.

[mcgilman]

You can avoid the @ts-ignore here by extending the optional chaining one level up — this lets the compiler handle the nullability without suppressing other potential errors:

const expectedCount = createUserResponse.userGroupUpdate?.userGroups?.length ?? 0;

[mcgilman]

Same pattern here:

const addedCount = updateUserResponse.userGroupUpdate?.userGroupsAdded?.length ?? 0;
const removedCount = updateUserResponse.userGroupUpdate?.userGroupsRemoved?.length ?? 0;

[mcgilman]

Good change wrapping in from() here. It makes the intent clearer. Would you mind doing the same in createUserSuccess$ (line 234)? It still returns the raw array there. Both work, but it'd be nice to keep them consistent.

return userGroupUpdates;