平台中用户查找、用户角色查询、用户权限查询、部门管理设置方法

本文详细介绍了如何在系统管理中查找用户、设置角色、查询权限、从机构继承权限及部门管理设置等关键步骤,包括如何通过菜单导航路径进行操作,并提供了一套完整的流程和示意图,帮助用户轻松掌握权限管理技巧。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

1.平台中用户查找

菜单导航路径
系统管理-权限管理-用户和机构管理

具体操作:
选择一个机构,输入登录名称,或者中文名称,选择是否递归查询,点击查询即可


img_8ab503a10d59897b537e4969143b846a.gif

2.用户角色设置和角色查询
菜单导航路径
系统管理-权限管理-用户和机构管理

具体操作:
按照第一条查询到需要操作的用户,在用户真实名称上点击右键-选择角色设置,示意图:


img_b4fda65219a0d16612276d37b98f42e8.gif

img_4da5d9a4e5559c2c1c26870ab889b9e1.gif

3.用户权限查询
参考上面出现的右键菜单,选择其中的权限查询项即可查询用户权限以及用户权限的来源(用户直接授予的权限、用户角色权限、roleofeveryone角色权限)



新建的用户默认拥有roleofeveryone角色,所有就拥有了roleofeveryone角色拥有的权限,查看roleofeveryone角色权限的方法:
菜单导航路径
系统管理-权限管理-角色管理
具体操作在roleofeveryone点击右键,选择权限查询,示意图:

img_645f25306c9814a76f6039b0f1117789.gif

img_a9aba97ccb03d4af948b6cfaa5e99d83.gif

权限配置文件(resources/resource-xxx.xml)中声明的unprotected资源权限,可以在【系统管理-资源查询-特殊资源查询】中查到,这些资源用户也会默认拥有,如果要去掉的话,参考下面的内容。权限配置文件(resources/resource-xxx.xml)中声明的unprotected资源权限查看和配置管理方法:
打开resources/resource-xxx.xml文件,找到资源定义,如下示意:
<resource id="column" name="菜单资源"  i18n:en_US="Menu Resource"   class="resColumnTree.jsp" auto="true" allowIfNoRequiredRole="false" struction="tree"  system="module,cms">
		<unprotected resourceid="personuserinfomodify" />
		<unprotected resourceid="personsecretpassword" />
		<unprotected resourceid="appManager" />
		<unprotected resourceid="appManageItem" />
					
		<!--<unprotected resourceid="contentManageItem" />-->
		<!--<unprotected resourceid="templetmanager" />-->
		<!--定义非未受保护的特殊资源-->
		<!--<unprotected resourceid="indexpage" >-->
		<!--<operation id="visible"/>-->
		<!--</unprotected>-->

		<!--unprotected resourceid="indexpage" ></unprotected>-->
		<!--<unprotected resourceid="sitebuilder" >-->
		<!--<operation id="unvisible"/>-->
		<!--</unprotected>-->
		<!--
		控制特定的资源除了超级管理员外,其他人都访问不了的资源
		-->
		<!--<exclude resourceid="sysuserpassword"/>-->
		<!--<exclude resourceid="sitebuilder">-->
		<!--<operation id="visible"/>-->
		<!--</exclude>-->
		<!--定义资源操作组-->
		<operationgroup groupid="group23"/>
	</resource>

其中的unprotected元素属性resourceid指定了一个所有认证用户都可以访问的资源权限。

4.用户可以从用户所属的机构继承权限,机构权限设置和管理方法:
系统管理-权限管理-用户和机构管理
在机构树上右键点击机构,在出现的右键菜单上可以进行角色设置、机构授权、权限查询、权限回收操作

5.部门管理设置
平台权限管理功能需要部门管理员用户和超级管理员才能访问,因此需要在权限管理中将相关的用户设置为部门管理员,设置方法如下:
菜单导航:
系统管理-权限管理-用户和机构管理

设置示意图:

orgmanager1.gif?raw=true

orgmanager2.gif?raw=true
本课程是一门具有很强实践性质的“项目实战”课程,即“企业中台系统实战”,其中主要包含三大块核心内容,如下图所示(右键可以在新标签页中打开图片放大查看): 即主要包含以下三大块内容: ① 企业内部应用系统菜单资源和操作权限的统一管理; ② 分布式应用系统通信时的统一授权,即基于AccessToken的授权与认证; ③ 分布式服务/系统通信时的两大方式(基于dubbo rpc协议和基于http协议的restful api实战)。   值得一提的是,这套中台系统由于讲解了如何统一管理企业内部各大应用系统的“菜单资源列表”、“操作权限”,故而本门课程的“代码实战”是建立在之前debug录制的“企业权限管理台”这套课程的基础之上的,故而在这里debug建议没有项目开发基础的小伙伴可以先去学习我的那套“企业权限管理台”的实战课程,之后再来学习我的这套中台系统的实战才不会很吃力(课程链接:)   本课程的课程大纲如下图所示(右键可以在新标签页中打开图片放大查看):   除此之外,这套“中台系统”由于统一管理了企业内部各大应用系统的“菜单资源和操作权限”以及“应用系统之间通信时的统一授权”,故而难免需要涉及到“中台系统”与“中台子系统”、“中台子系统”与“中台子系统”之间的通信(即分布式服务之间的通信),在这里我们是采用“dubbo + zookeeper”的方式加以落地实现的,详情如下图所示(右键可以在新标签页中打开图片放大查看):   而众所周知,作为一款知名以及相当流行的分布式服务调度中间件,dubbo现如今已经晋升为Apache顶级的开源项目,未来也仍将成为“分布式系统”开发实战的一大利器,如下图所示为dubbo底层核心系统架构图(右键可以在新标签页中打开图片放大查看): 而在这门“中台系统实战”的课程中,我们也将始终贯彻、落地dubbo的这一核心系统架构图,即如何将中台系统开发的服务注册/发布到注册中心zookeeper,中台子系统如何订阅/消费/调度中台系统发布在zookeeper的接口服务,中台子系统在走http协议调度通信时dubbo如何进行拦截、基于token认证接口的调用者等等,这些内容我们在课程中将一一得到代码层面的实战落地!   下图为本课程中涉及到的分布式系统/服务之间 采用“http协议restfulapi”方式通信时的Token授权、认证的流程图(右键可以在新标签页中打开图片放大查看): 而不夸张地说,基于AccessToken的授权、认证方式在现如今微服务、分布式时代系统与系统在通信期间最为常用的“授权方式”了,可想而知,掌握其中的流程思想是多么的重要!   以下为本门课程的部分截图(右键可以在新标签页中打开图片放大查看):     核心技术列表: 值得一提的是,由于本门课程是一门真正介绍“中台思想”以及将“中台思想”和“分布式系统开发实战”相结合落地的课程,故而在学完本门课程之后,可以掌握到的核心技术自然是相当多的。主要由SpringBoot2.0、SpringMVC、Mybatis、Dubbo、ZooKeeper、Redis、OkHttp3、Guava-Retrying重试机制、JWT(Json Web Token)、Shiro、分布式集群session共享、Lombok、StreamAPI、Dubbo-Filter以及ServiceBean等等。如下图所示(右键可以在新标签页中打开图片放大查看):
### 用户角色部门和岗位的权限管理 #### 实现及配置概述 在一个完善的权限管理系统中,用户角色部门和岗位之间的关系紧密相连。为了有效管理和分配权限,系统设计应考虑以下几个方面: - **用户管理**:涉及创建、删除、冻结/解冻账户等功能[^3]。 - **角色定义**:基于企业内部结构设定不同职位的角色,如销售经理、财务总监等,赋予相应的操作权限。 - **部门设置**:按照实际业务划分成若干个独立运作单元——部门;每个部门内又细分为具体的工作小组或团队。 - **岗位授权**:针对特定工作职能设立专门职务名称(例如项目经理),为其指定具体的任务清单以及所能接触的数据范围。 以下是构建这样一个综合性的权限管理体系的具体方法和技术细节说明: #### 数据库表结构设计 对于实现上述提到的功能模块而言,合理的数据库设计方案至关重要。这里给出了一种可能的设计思路: 1. `users` 表存储所有注册用户的个人信息及其状态; 2. `roles` 表记录各种预设好的角色信息,包括但不限于ID编号、中文描述名等字段; 3. `departments` 表用来表示各个职能部门的信息,同样具有唯一标识符和其他辅助属性; 4. `positions` 表保存每类工作岗位的相关资料,它与前两张表格存在外键关联,从而形成完整的三层级架构体系; 5. `permissions` 表列举了整个应用台中存在的全部可用权限项; 6. 中间件连接表用于维护多对多映射关系,比如 `user_roles`, `role_permissions` 和 `department_positions`. ```sql CREATE TABLE users ( id INT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50), password_hash CHAR(64), -- 使用哈希算法加密后的密码字符串长度固定为64位 status ENUM('active', 'frozen') DEFAULT 'active', created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE roles ( role_id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(100) UNIQUE NOT NULL COMMENT '角色名称' ); CREATE TABLE departments ( dept_id INT PRIMARY KEY AUTO_INCREMENT, title VARCHAR(100) UNIQUE NOT NULL COMMENT '部门名称' ); CREATE TABLE positions ( pos_id INT PRIMARY KEY AUTO_INCREMENT, description TEXT NOT NULL COMMENT '岗位职责介绍' ); CREATE TABLE permissions ( perm_id INT PRIMARY KEY AUTO_INCREMENT, action_code VARCHAR(50) UNIQUE NOT NULL COMMENT '权限编码' ); ``` #### 后端逻辑处理流程 在应用程序层面,则需遵循以下原则来进行开发: - 当新员工入职时,在HRIS系统完成基本信息录入后同步至本项目中的`users`表里建立相应条目;与此同时根据其所在部门自动匹配默认初始角色(如果有的话)或将此步骤留待后续手动指派; - 对于现有成员来说,任何有关调动升迁的消息都应及时更新到对应的数据库记录当中去,确保最新变动能够反映出来; - 鉴权环节应当贯穿始终,无论何时何地只要涉及到敏感资源请求均要先验证当前主体是否具备足够的许可级别才能给予放行指示; - 定期审查现有的权限分配策略是否存在漏洞或者冗余之处,必要时做出适当调整优化以保障整体安全性不受威胁。 #### 前端界面交互体验 最后就是如何让用户方便快捷地操作这套复杂的权限控制系统了。考虑到用户体验的重要性,建议采取如下措施提升易用性: - 提供直观清晰的操作面板让管理者能快速浏览查看已存在的各类实体对象列表视图; - 支持批量编辑模式以便一次性修改大量相似性质的内容而不必逐一点击确认; - 设计友好的提示框帮助初次使用者理解各项功能用途的同时减少误触几率; - 加入搜索过滤器使得查找目标更加精准高效节省时间成本。 通过以上几个方面的努力,可以建立起一套既满足企业管理需求又能保护信息安全的有效工具。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值