lizhimins commented on PR #4321: URL: https://github.com/apache/rocketmq-dashboard/pull/4321#issuecomment-5694515664
Closing: this is the same change we closed in #4162 about an hour before this PR was opened — `DeleteRole` -> `ModifyRole` with `permRead=false` / `permWrite=false`, plus the `listRules` filter that hides roles whose permissions are both false. The reasoning there still stands: - in trocket a Role *is* the ACL principal, which is why `deleteUser` and `deleteRule` both call `DeleteRole`; routing only `deleteRule` to `ModifyRole` leaves the cloud-side Role in place after Studio has told the user the rule was deleted, and makes the two delete entry points mean different things; - hiding roles with both permissions false makes Studio's view diverge from the cloud's real state, and a Role that reaches that state outside Studio becomes invisible and therefore unmanageable from here; - we still have no evidence that `ModifyRole` with both permissions false is an accepted, meaningful state in the trocket API rather than an error or a no-op. The instinct — do not destroy a shared cloud Role on a rule delete — is reasonable. As suggested in #4162, please open an issue with console/API evidence for that state and a story for the leftover Role and the divergent `deleteUser` path, and we will pick it up there. -- 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]
