Repository navigation
feat: system identity user permission - #7741
Conversation
| <ButtonChangeUserPassword v-if="perm.system.user.edit()" :user="row" @refresh="loadSystemUsers(false)" /> | ||
| <!-- 删除 --> | ||
| <MkTooltip content="删除" placement="top" v-if="perm.system.user.delete()"> | ||
| <el-button type="primary" text @click.stop="deleteUser(row)"> |
There was a problem hiding this comment.
Here's my review of this diff:
Summary of the change:
A permission check v-if="perm.system.user.edit()" was added to ButtonChangeUserPassword, aligning it with the adjacent delete button which already has a permission guard.
Assessment:
-
Good — Consistency improved: The delete button already had
v-if="perm.system.user.delete()", but the "change password" button had none. Adding a permission gate is the correct fix. -
Questionable — Correct permission used? Changing a user's password may not logically map to the
editpermission. Verify whether:- There is (or should be) a distinct permission such as
perm.system.user.changePassword()/resetPassword(). - Password changes should require a stronger privilege than a general "edit" (this is a sensitive, security-critical operation). Consider whether
edit()is the right gate or if it silently grants too much.
- There is (or should be) a distinct permission such as
-
Potential issue — Backend enforcement: A front-end
v-ifonly hides the UI. Ensure the backend API endpoint that changes/resets a user's password also enforces the same permission (never rely on the client). Confirm this exists. -
Consistency nit: The other buttons (
MkTooltip, delete) use different wrapper patterns. Herev-ifis placed directly onButtonChangeUserPassword, whereas delete wrapsel-buttonin anMkTooltip. That's fine, but confirmButtonChangeUserPasswordrenders nothing undesirable when hidden (e.g., no stray tooltip/wrapper). Sincev-ifremoves the whole component, this is OK. -
No hook/binding concern visible: Nothing in this hunk suggests reactivity problems;
permappears to be a reactive object used elsewhere in the template. -
Style: Inline
v-ifis consistent with the surrounding code — acceptable here.
Recommendation: Keep the change (it fixes a real UI-permission gap), but (a) confirm perm.system.user.edit() is the semantically correct and sufficiently privileged check for password changes, and (b) verify the backend enforces the same check. If password reset warrants its own permission, use that instead.
feat: system identity user permission