lizhimins commented on PR #4122: URL: https://github.com/apache/rocketmq-dashboard/pull/4122#issuecomment-5601979563
Closing as folded into #4113, which was merged into `rocketmq-studio` as 0c54d985. 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. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
