lizhimins commented on PR #4162: URL: https://github.com/apache/rocketmq-dashboard/pull/4162#issuecomment-5679164053
Thanks for the patch. We're closing it because it doesn't match how the Tencent side actually behaves, and it splits the delete semantics inside one service. Concretely, from the current code: `deleteUser` (`TencentAclService.java:207-214`) and `deleteRule` (`:242-249`) both call `DeleteRole`, because in trocket a "Role" *is* the ACL principal. Routing `deleteRule` to `ModifyRole` with `permRead=false`/`permWrite=false` leaves the cloud-side Role in place after Studio has told the user the rule was deleted — the resource is still there in the Tencent console, and the two delete entry points now mean different things. The companion filter in `listRules` compounds it: hiding roles whose read and write perms are both false makes Studio's view diverge from the cloud's actual state, and a Role that reaches that state outside Studio becomes invisible and therefore unmanageable from here. We also can't confirm that `ModifyRole` with both permissions false is an accepted, meaningful state in the trocket API rather than an error or a no-op. If you have console/API evidence that it is, and a story for the leftover Role and the divergent `deleteUser` path, please reopen the discussion in an issue first — the "don't destroy a shared cloud Role on a rule delete" instinct is reasonable, but it needs to hold against the real API. -- 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]
