elunez/eladmin · error · BadRequestException

所选部门存在用户关联，请解除后再试！

Error message

所选部门存在用户关联，请解除后再试！

What it means

Thrown by DeptServiceImpl.verification (line 245) during dept deletion when userRepository.countByDepts(deptIds) > 0 — at least one selected department still has users attached. eladmin deletes departments only when they are fully unreferenced; this guard runs before removal so the tree stays consistent.

Source

Thrown at eladmin-system/src/main/java/me/zhengjie/modules/system/service/impl/DeptServiceImpl.java:245

            } else if(deptDTO.getPid() != null &&  !deptNames.contains(findById(deptDTO.getPid()).getName())) {
                depts.add(deptDTO);
            }
        }

        if (CollectionUtil.isEmpty(trees)) {
            trees = depts;
        }
        Map<String,Object> map = new HashMap<>(2);
        map.put("totalElements",deptDtos.size());
        map.put("content",CollectionUtil.isEmpty(trees)? deptDtos :trees);
        return map;
    }

    @Override
    public void verification(Set<DeptDto> deptDtos) {
        Set<Long> deptIds = deptDtos.stream().map(DeptDto::getId).collect(Collectors.toSet());
        if(userRepository.countByDepts(deptIds) > 0){
            throw new BadRequestException("所选部门存在用户关联，请解除后再试！");
        }
        if(roleRepository.countByDepts(deptIds) > 0){
            throw new BadRequestException("所选部门存在角色关联，请解除后再试！");
        }
    }

    private void updateSubCnt(Long deptId){
        if(deptId != null){
            int count = deptRepository.countByPid(deptId);
            deptRepository.updateSubCntById(count, deptId);
        }
    }

    private List<DeptDto> deduplication(List<DeptDto> list) {
        List<DeptDto> deptDtos = new ArrayList<>();
        for (DeptDto deptDto : list) {
            boolean flag = true;
            for (DeptDto dto : list) {

View on GitHub (pinned to 55fbf70595)

Solutions

1. Reassign those users to another dept first (user edit screen or bulk UPDATE sys_user_dept), then retry the delete.
2. Identify blockers: SELECT user_id, dept_id FROM sys_user_dept WHERE dept_id IN (...).
3. If users are truly obsolete, delete the users (respecting role-level rules) before deleting their depts.

// Before DELETE /api/dept, ensure no users reference the dept(s)
const { data } = await axios.get('/api/dept'); // or a dedicated user-by-dept query
// Practically: surface the server message and link to user reassignment.
// Server-side pre-check if you build a wrapper service:
long n = userRepository.countByDepts(Set.of(deptId));
if (n > 0) throw new IllegalStateException("reassign " + n + " users first");

Catch the 400, parse the count-free message, and route the admin to user reassignment; do not retry the delete unchanged.

When it happens

Trigger: DELETE /api/dept with an id whose sys_user_dept rows still exist; deleting a whole subtree where one leaf dept contains active or disabled users; batch delete including the default dept that new users were assigned to.

Common situations: Admins cleaning up an org restructure while users are still mapped to old depts; test data left assigned to scratch departments; disabled/departed users still counting because delete is the only thing checked, not enabled state.

Related errors

• 所选部门存在角色关联，请解除后再试！
• 角色权限不足，不能删除：{username}
• 所选的岗位中存在用户关联，请解除关联再试！
• 所选角色存在用户关联，请解除关联再试！
• A new dept cannot already have an ID

AI-assisted analysis of elunez/eladmin@55fbf70595 (2026-08-14). Data as JSON: /api/errors/d7bb66e847ef853e. Report an issue: GitHub.