fix(acl): keep the account whitelist in the update response

[zjncs]

Motivation

AclService.updateUser (local plain-access path) carefully preserves every existing field of the account through a partial update — accessKey, secretKey, admin, clusters, gmtCreate — but the merge builder omits whiteRemoteAddress:

AclUserVO merged = AclUserVO.builder()
        .id(existing.getId())
        .username(...)
        .accessKey(existing.getAccessKey())
        .secretKey(existing.getSecretKey())
        .admin(...)
        .clusters(...)
        .gmtCreate(existing.getGmtCreate())
        .build();

whiteRemoteAddress is a real, persisted field of local plain-access accounts (rmq_acl_user.white_remote_address, written by createAndUpdatePlainAccessConfig, read back by toUserVO). The stored row survives the update (MyBatis-Plus updateById skips null columns), but replaceUser returns the merged VO, so POST /api/acl/users/update responds with whiteRemoteAddress: null after a harmless rename — the API reports the account's IP whitelist as gone even though it is still enforced.

Modifications

Carry existing.getWhiteRemoteAddress() through the merge, like every other preserved field.

Verification

New test updateUserShouldKeepTheExistingWhiteRemoteAddress (model: updateUserShouldSaveExistingUser): existing user with whiteRemoteAddress = "10.0.1.0/24", rename via DTO.

• Before the fix: fails — whiteRemoteAddress in the response is null.
• After the fix: passes.
• ACL suite regression: mvn -f server/pom.xml test -Dtest='AclServiceTest,MybatisPlusAclRepositoryTest,AclControllerTest' → Tests run: 114, Failures: 0, Errors: 0.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[RockteMQ-AI]

Summary

Fixes a field omission in AclService.updateUser where whiteRemoteAddress was not carried through the merge builder, causing the API to respond with null after a harmless rename even though the stored row was preserved. One-line fix. LGTM.

---

Automated review by RockteMQ-AI

[lizhimins]

Closing as folded into #4113, which was merged into rocketmq-studio as 0c54d98.

Your diagnosis and your fix here were correct and are now on the branch: AclService.updateUser merges the incoming account onto the stored one but never carried whiteRemoteAddress across, so the update response reported a null whitelist even though MybatisPlusAclRepository.toUserEntity does not map white_remote_address at all — meaning the column is untouched by replaceUser and this was purely a response-shape defect. That matters in practice because web/src/pages/instance/acl.tsx replaces its local row with the response and does not refetch, so the whitelist visibly disappeared until the next reload. The one-line .whiteRemoteAddress(existing.getWhiteRemoteAddress()) in the merged builder is exactly what shipped.

The reason this landed inside #4113 rather than on its own: both PRs fix the same ACL account read/write path, arrived within an hour of each other from the same author, and neither touches a file the other does. We group related same-author changes into one commit on the target PR so the branch history stays readable, and #4113 was the target here. Your updateUserShouldKeepTheExistingWhiteRemoteAddress test came across with the fix and passes as part of AclServiceTest (65 tests green).

Nothing further needed from you — thank you for the fix and for the precise write-up of why a null whitelist in the response is user-visible rather than cosmetic.