perms-system-server/internal/logic/role/updateRoleLogic.go

package role

import (
	"context"
	"errors"
	"time"

	"perms-system-server/internal/consts"
	"perms-system-server/internal/loaders"
	authHelper "perms-system-server/internal/logic/auth"
	"perms-system-server/internal/middleware"
	roleModel "perms-system-server/internal/model/role"
	"perms-system-server/internal/response"
	"perms-system-server/internal/svc"
	"perms-system-server/internal/types"

	"github.com/zeromicro/go-zero/core/logx"
)

type UpdateRoleLogic struct {
	logx.Logger
	ctx    context.Context
	svcCtx *svc.ServiceContext
}

func NewUpdateRoleLogic(ctx context.Context, svcCtx *svc.ServiceContext) *UpdateRoleLogic {
	return &UpdateRoleLogic{
		Logger: logx.WithContext(ctx),
		ctx:    ctx,
		svcCtx: svcCtx,
	}
}

// UpdateRole 更新角色。修改角色名称、备注、权限级别和启用/禁用状态。
//
// 权限级别约定（与 UserDetailsLoader.loadRoles / MinPermsLevel 计算一致）：
// **数字越小 = 权限越高**（MinPermsLevel 取当前用户所有启用角色 permsLevel 的最小值）。
// 因此 `req.PermsLevel < role.PermsLevel` 表示"把角色调到比当前更高的权限"，非超管该路径被拒绝。
//
// 变更后自动清理绑定该角色的用户缓存（BatchDel 是尽力而为，失败仅记日志由 TTL 兜底）。
// 审计 L-R12-3：此处历史注释曾写作"非超管不能**降低**权限级别"，与代码实际语义相反；
// 已改为"非超管不能**提升**权限级别"，并在本注释显式钉上"数字越小 = 权限越高"的约定。
func (l *UpdateRoleLogic) UpdateRole(req *types.UpdateRoleReq) error {
	// 审计 L-R14-1：非超管看到"非本产品 roleId"必须伪装成 404，避免 404 vs 403 文案
	// 差异泄漏跨产品 roleId 存在性；与 RoleDetailLogic 的 M-N3 口径完全一致。
	role, err := authHelper.ResolveOwnRoleOr404(l.ctx, l.svcCtx, req.Id)
	if err != nil {
		return err
	}

	if err := authHelper.RequireProductAdminFor(l.ctx, role.ProductCode); err != nil {
		return err
	}

	if len(req.Name) > 64 {
		return response.ErrBadRequest("角色名长度不能超过64个字符")
	}
	if len(req.Remark) > 255 {
		return response.ErrBadRequest("备注长度不能超过255个字符")
	}

	if req.PermsLevel < 1 || req.PermsLevel > 999 {
		return response.ErrBadRequest("权限级别必须在 1-999 之间")
	}

	caller := middleware.GetUserDetails(l.ctx)
	// 审计 L-R12-3：数字越小 = 权限越高；`req.PermsLevel < role.PermsLevel` 即"把角色调更高权"。
	// 非超管 product ADMIN 在本产品内有全权，提升 / 降低都不构成越权；真正的越权边界由
	// BindRoles 的 GuardRoleLevelAssignable 守住（caller 不能把比自己 MinPermsLevel 更高权
	// 的角色绑到他人）。本校验仅作为"不让 non-super 在产品内通过改角色权级把自己悄悄顶到
	// 超管线"的护栏，防御面较窄但留着成本可忽略。
	if caller != nil && !caller.IsSuperAdmin && req.PermsLevel < role.PermsLevel {
		return response.ErrForbidden("非超管不能提升角色的权限级别")
	}

	prevUpdateTime := role.UpdateTime
	prevName := role.Name
	role.Name = req.Name
	role.Remark = req.Remark
	role.PermsLevel = req.PermsLevel
	if req.Status != 0 {
		if req.Status != consts.StatusEnabled && req.Status != consts.StatusDisabled {
			return response.ErrBadRequest("状态值无效，仅支持 1(启用) 和 2(禁用)")
		}
		role.Status = req.Status
	}
	role.UpdateTime = time.Now().Unix()

	if err := l.svcCtx.SysRoleModel.UpdateWithOptLock(l.ctx, role, prevUpdateTime); err != nil {
		if errors.Is(err, roleModel.ErrUpdateConflict) {
			return response.ErrConflict("数据已被其他操作修改，请刷新后重试")
		}
		return err
	}

	// 角色已经更新成功，缓存清理属于尽力而为：failure 仅记录 Errorf，不映射为 500，
	// 否则客户端会把"角色已改但缓存未刷"的 degraded 成功误判为完全失败而重试（见审计 M-4）。
	// 旧权限缓存最多在 TTL 窗口内继续生效，由 TTL 过期兜底。
	cleanCtx, cancel := loaders.DetachCacheCleanCtx(l.ctx)
	defer cancel()

	// 审计 H-R18-1：UpdateWithOptLock 内部只失效 (id) 与 (productCode, 新 name) 两把键；
	// 如果本次 rename 改了 name，旧 (productCode, oldName) 索引键不会被清，Redis 里还指向
	// 原主键，导致 FindOneByProductCodeName(oldName) 在 TTL 窗口（默认 7 天）继续命中脏行。
	// 对齐 DeleteRoleLogic 的 post-commit InvalidateRoleCache 模式补一次显式失效。
	if prevName != role.Name {
		l.svcCtx.SysRoleModel.InvalidateRoleCache(cleanCtx, role.Id, role.ProductCode, prevName)
	}

	if affectedUserIds, err := l.svcCtx.SysUserRoleModel.FindUserIdsByRoleId(l.ctx, req.Id); err == nil {
		// 审计 L-R13-5 方案 A：角色 permsLevel/status 变更影响所有持有者 loadPerms 的授权判定，
		// post-commit BatchDel 必须脱离请求 ctx——批量清理涉及多次 Redis RTT，遇到请求取消更
		// 容易半途终止；这里的停用一旦滞留到 TTL 结束，就是 5 分钟内越权授权。
		l.svcCtx.UserDetailsLoader.BatchDel(cleanCtx, affectedUserIds, role.ProductCode)
	} else {
		logx.WithContext(l.ctx).Errorf("UpdateRole roleId=%d 角色已更新但 FindUserIdsByRoleId 失败，用户权限缓存将等待 TTL 自然过期: %v", req.Id, err)
	}
	return nil
}