Skip to content

第二章:数据的守护者—— 配置角色与权限控制

试想,在一个真正的企业环境中,如果所有的员工都能看到:

  1. 敏感字段: 所有人都能打开【员工表】,查看其他人的“薪资”、“绩效等级”等核心隐私数据。
  2. 非职责模块: 财务人员可以访问 HR 的【人力资源看板】,或普通员工可以进入【应用设计器】进行修改。
  3. 跨部门数据: 研发部的主管能查看市场部员工的绩效记录。

显然,这是不可接受的。

织信低代码平台通过其强大的 “角色权限(⻆⾊权限)”机制,为您提供了一套精密的三层权限防护体系,确保每个用户都只能在授权的范围内“看”和“操作”数据:

权限层级安全作用(比喻)织信对应功能
模块级“大门门禁”:决定用户能进入哪个功能区(模块)。模块设置、角色权限
字段级“文件遮罩”:进入模块后,隐藏或只读特定字段。字段设置 - 权限
记录级(行级)“激光围栏”:动态过滤,只显示与用户职责相关的数据记录。数据表视图 - 动态筛选条件

本章将引导您一步步实践,为您的应用配置这三道安全防线,打造坚不可摧的数据堡垒

2.1 核心概念:角色——权限的“数字通行证”

在织信中,权限控制的核心是 RBAC (Role-Based Access Control,基于角色的访问控制)。权限不是直接授予给某个用户“张三”或“李四”,而是授予给一个角色(如“部门主管”)。如果您需要更详细的了解织信的角色概念,可以点击此链接角色权限 | 织信低代码平台开发文档

为什么要基于角色?

这样您就不需要为每一位新员工单独配置几十项权限。您只需将新员工分配到预设好的角色中,他们就能立刻获得该角色的所有权限,极大地简化了用户管理和授权流程。

一个用户可以拥有多个角色,从而获得多个角色的权限集合。例如,一个员工可以同时是“部门主管”和“HR”,他将拥有这两个角色的所有权限。

RBAC

2.1.1 实践准备:创建和分配核心角色

为了实现精细化管理,我们首先在应用内创建并配置两个自定义角色:

  1. 进入角色权限管理: 在应用设计器中,找到 【全局设置-角色权限】 模块。

    47de9e1f-4e97-4003-96e3-a60ab54eba76

  2. 创建自定义角色:

    创建以下三个自定义角色(系统默认已有“管理员”,因为管理员拥有系统的全部权限,除了需要对应用进行开发的人员,请不要把管理员权限给与公司的任何员工):

    • 【HR 专员】:可以查看和编辑所有员工的完整数据,拥有最高的 HR 数据权限。

    • 【部门主管】:负责审批本部门请假,只能查看和编辑自己部门的员工数据。

    • 【普通员工】:只能查看自己的数据。

      image-20250927095009851

  3. 配置角色标识符: 在创建自定义角色时,织信支持自定义和修改角色的标识符。请确保标识符清晰(一般使用角色的英文单词即可,标识符中不要出现空格),因为高级权限配置(如表达式,脚本)会依赖这些标识符进行计算。

image-20250927094907435

2.1.2 为应用添加成员,并分配角色

创建好了“角色”之后,下一步就是将公司的同事们“请”进这个应用,并为他们配置各自正确的角色。

首先,进入应用设计器,添加应用成员管理模块如下图:

69a3a43ef80465e63e66e698a5b79bd8

添加完成后,直接发布应用即可。接下来进入应用,我们就能看到成员管理界面,这里列出了所有有权限访问本应用的用户(目前应该只有您自己)。

ae507cec-6093-4a29-a83e-a1e981d12860

添加应用成员:

  1. 点击页面左上角的 + 新增成员 按钮。

  2. 在弹出的窗口中,您可以从您企业通讯录(组织架构)中,选择需要访问本应用的同事和他们的角色,选择然后确认添加。

    19e011f3-8918-4eea-819d-3950bb9fde34

为成员修改角色:

将成员添加到应用后,他们的角色可能发生变化,我们可以进行修改。

  1. 在成员列表中,找到添加的同事。
  2. 点击该行中的“编辑”图标(铅笔样式)。
  3. 在弹出的角色选择菜单中,为该成员选择一个最符合其岗位的角色。例如:
    • 为您的主管账号选择 【部门主管】 角色。
    • 为您的 HR 账号选择 【HR 专员】 角色。
    • 为您的普通员工账号选择 【普通员工】 角色。
    • 为了后续的测试方便,您可以同时把自己设置 【管理员】【部门主管】【HR 专员】【普通员工】 四个角色。

2.2 实践一:模块级权限控制(门禁管理)

模块级权限是权限体系的第一道防线,它决定了用户登录应用后,能在左侧导航栏中看到哪些功能入口。

设置具体角色的权限: 点击上面步骤创建的任一角色,您会看到如下界面。

b23e5e82-99b0-4d31-bb80-7d5d3fe8b0cd

在上图中:

访问应用:只有勾选这个权限的角色才能真正的使用我们的员工管理系统,理论上您创建的所有角色都应该勾选这个权限。

成员管理:拥有这个权限的角色可以为自行为我们的员工管理系统添加或者删除用户。

查看模块:这是针对具体模块(如“部门表”、“员工表”)的权限。勾选后,代表该角色可以访问或查看对应的模块。

查询数据:代表允许该角色查看模块中当前已经存在的数据

新建数据 :代表允许该角色在模块中创建新的数据记录。

编辑数据:代表允许该角色编辑已存在的数据记录。

删除数据 :代表允许该角色删除数据记录。

下面我们针对的具体的角色进行权限的分析和配置:

普通员工:普通员工可以查看员工表中自己的数据,所以他可以查看员工模块,查询数据,但是他不应该能够创建新员工,也不应该能够修改现有员工的数据,更不应该能够删除现有的员工。因此他的权限配置如下(修改后请记得点击保存权限):

image-20250927113249150

部门主管: 部门主管可以查看并管理自己部门下的所有员工数据。所以他可以查看员工模块,查询自己部门的员工数据。因此他的模块权限和普通员工一致,部门主管和员工的区分主要在后面我们会介绍的数据和字段权限不同。

HR 专员: HR 专员可以查看并管理全公司的员工数据。所以他可以查看员工模块,查询公司内所有员工的数据,并且能够创建新员工,修改现有员工的数据。但是通常不应该能够删除现有的员工(离职一般应该走专门的离职流程,而不是简单的删除数据,这个功能我们将在后面的高阶应用文档中展示)。因此他的权限如下:

image-20250927114158777

2.3 实践二:字段级权限控制(数据遮罩)

字段级权限控制用于保护数据表单内的单个字段。这是保护如薪资、合同信息等敏感数据的关键手段。

场景: 在【员工表】中,我们新增一个敏感字段:“薪资”

image-20250927114607764

我们必须确保【部门主管】和【普通用户】无法看到它,只有 HR 专员可以看到该字段。

  1. 进入字段设计: 进入【员工表】模块,然后点击 “表单字段” 标签页,找到并点击 “薪资” 字段,进入字段的详细设置。

  2. 配置权限:在字段设置面板的底部,找到 【权限】 选项卡,勾选在表单中隐藏此字段。

    55d779c0-5ad1-40aa-8ce6-404b45913cdb

    在勾选此选项后,这个字段将对所有用户隐藏。那么,如何实现对 HR 专员可见的功能呢?这就需要用到织信的另一个重要能力:条件编辑器。点击在表达式满足时在表单中可见这个输入框, 系统将为您弹出条件编辑器窗口。

2.4 规则设定中心:条件编辑器

2.4.1 条件编辑器是做什么用的?

您可以将“条件编辑器”想象成一个应用的“智能大脑”或“规则设定中心”。

它的核心作用是,让你能为应用的各种行为(如字段的显示/隐藏、是否必填等)设定动态的、可变的触发条件。普通的功能设置是“一刀切”的静态规则(例如,一个字段永远隐藏),而条件编辑器则能让你实现“如果…那么…”的智能化、精细化控制。

通过它,你的应用将不再是死板的表单,而是能够根据当前登录的人、当前的数据内容、甚至是当前的时间,来动态改变其行为和外观的智能系统。

2.4.2 界面功能详解

2e1659cf9a81c98b1eb750f8cb35df14

整个条件编辑器的界面主要由以下几个部分构成:

A. 条件组逻辑

满足下列 [所有 / 任意] 条件时

这是整个条件组的“主逻辑开关”,它决定了当你设置了多条条件时,它们之间应该是什么关系。

  • 所有 (AND 逻辑):
    • 含义: 必须同时满足下面定义的所有条件,整个规则才算成立。
    • 例子: 如果你设置了两个条件:1. 当前用户.角色 包含 部门主管,2. 当前记录.状态 等于 审批中。那么只有当一个部门主管在查看一条审批中的记录时,这个规则才会生效。
  • 任意 (OR 逻辑):
    • 含义: 只要满足下面定义的任意一个条件,整个规则就算成立。
    • 例子: 如果你设置了两个条件:1. 当前用户.角色 包含 部门主管,2. 当前用户 等于 当前记录.创建人。那么无论是部门主管,还是记录的创建者本人,在查看这条记录时,规则都会生效。

B. 条件行

每一行都是一条独立的、具体的判断规则,它由三个部分组成,共同构成一个完整的“主谓宾”逻辑句式。

[检查对象] [比较方式] [目标值]

  • 第一部分: 检查对象 (主语)

    • 功能: 定义了“我们要检查什么东西?”。点击添加判断条件后,系统会让你从当前的“上下文”中选择一个动态变量。

      c53bf10ecb0c96c9fae6d4b8039055b6

    • 常见变量:

      • 当前用户: 指正在操作系统的这个人。你可以获取他的姓名、角色、所属部门等信息。
      • 当前记录: 指正在被查看或编辑的这条数据。你可以获取这条数据中任何一个字段的值。
      • 系统变量: 可以获取当前的系统时间等信息。
  • 第二部分: 比较方式 (谓语)

    • 功能: 定义了“我们用什么方法来比较?”。这是一个比较运算符。
    • 常见运算符:
      • 等于 / 不等于: 进行精确匹配。
      • 包含 / 不包含: 判断一个列表(如用户角色)是否包含某个值。
      • 大于 / 小于 / 大于等于 / 小于等于: 用于数字或日期的比较。
      • 为空 / 不为空: 判断某个字段是否填写了内容。
  • 第三部分: 目标值 (宾语)

    • 功能: 定义了“我们的标准是什么?”。这是一个你设定的、用于比较的固定值。
    • 值的类型: 它可以是一个具体的角色(如“HR 专员”)、一个文本(如“已批准”)、一个数字或是一个日期。

C. 操作按钮

  • 删除按钮: 位于每条条件行的右侧,用于删除当前条件
  • 确定 / 取消: 位于编辑器底部,用于保存你构建的这套规则,或放弃修改。

2.4.3 它可以用来做什么?

条件编辑器的应用场景极为广泛,远不止于控制字段的可见性。以下是一些常见的例子:

  • 场景一:动态可见性 (本例)

    • 需求: “薪资”字段只对“HR 专员”可见。
    • 规则: 当前用户.应用角色列表 包含任意一个 HR专员,按照下图中配置,并点击确定即可

    2e1659cf9a81c98b1eb750f8cb35df14

  • 场景二:数据校验

    • 需求: 项目管理中,任务的“实际完成时间”不能早于“计划开始时间”。
    • 规则: 为“实际完成时间”字段设置校验条件 -> 当前记录.实际完成时间 小于 当前记录.计划开始时间 -> (若满足则报错)
  • 场景三:动态只读

    • 需求: 申请单一旦进入“审批中”状态后,“申请事由”字段就不能再被修改。
    • 规则: 为“申请事由”字段设置只读条件 -> 当前记录.审批状态 不等于 草稿
  • 场景四:按钮权限控制

    • 需求: 审批页面上的“驳回”按钮,只有“部门主管”以上级别的角色才能看到。
    • 规则: 为“驳回”按钮设置显示条件 -> 当前用户.角色 包含 部门主管 当前用户.角色 包含 总经理

2.5 实践三:记录级(行级)权限控制(上)

记录级权限控制是三层防护中最复杂,也是最具企业级管理色彩的一环。它要求系统能够根据当前登录用户的身份、部门、职位等信息,动态地过滤其能看到的数据行。

场景: 我们必须确保 【普通员工】 角色,无论通过何种方式访问【员工表】,都只能看到属于他自己的员工记录,而看不到其他人的数据。

显然,我们需要优先解决一个问题,我们该如何知道当前访问应用的用户是公司的哪一位员工?换言之,我们该如何在系统中建立用户账号和员工表数据的关联关系?

2.5.1 前置操作 1:员工表添加“关联账号”字段

为了解决这个问题,我们就要先在员工表中再添加一个“关联账号”的字段。这个字段将像一座桥梁,把抽象的“系统登录用户”和具象的“员工信息记录”精准地连接起来。

7ec936ef-a91f-4b0b-bab8-d812cc1f51cb

字段创建完成后,发布应用。接下来需要为现有数据填充这个字段。

  1. 进入【员工表】的数据视图。

  2. 编辑每一条已存在的员工记录,在“关联账号”字段中,为他们选择对应的系统用户。

    4537b708b7d03e3506f47cc2e745f7e4

完成这一步后,我们的准备工作才算真正大功告成。现在,系统中的每一条员工记录,都通过“关联账号”字段,与一个唯一的用户身份牢牢绑定。我们已经拥有了实现记录级权限控制的最关键前提

接下来,我们就可以利用这个“绑定关系”,去创建那条核心的权限规则了。

2.5.2 步骤一:创建组合查询条件

在入门教程中我们提到,视图(视图)是从数据仓库(数据表)中提取数据并按规则呈现的 “精致展厅”。我们要为【普通用户】创建一个专用的“展厅”。

  1. 进入视图设置: 进入【员工表】模块,点击 【表格设置】 标签页,然后点击进入下一级的 【筛选条件】 标签页。

    c59af541-ef6f-43ac-a876-7d06ab9ede0e

  2. 点击添加按钮,开始添加过滤器。

    38e2044f07444f8f3eff4fe527e34e90

2.5.3 步骤二:为普通员工配置动态过滤器

与我们在《快速入门》中设置的、对所有用户都生效的“固定筛选条件”不同,“动态过滤器”是一个智能的、个性化的过滤层。它能够根据当前访问这个视图的用户是谁,来动态地决定 “这个视图是否对他可见” 以及 “他能在视图中看到哪些数据”

根据页面布局,动态过滤器主要包含两大核心功能:

1. 视图可见性

  • 页面说明:“设置过滤条件,满足条件的用户才可以看到此视图”

  • 功能解读: 此功能用于控制整个视图的访问权限。您可以把它理解为给这个视图的入口设置了一个“智能门禁”。只有符合您所设定的条件的用户,才能在应用的导航菜单中看到并进入这个视图。对于不符合条件的用户,这个视图就如同不存在一样。

  • 对于当前场景,我们可以设置视图只对普通员工可见。。

    image-20250927162118477

2. 数据过滤

  • 页面说明:“设置动态过滤条件,视图打开时仅显示满足条件的数据”

  • 功能解读: 此功能用于根据当前访问者的身份,动态地过滤视图中所显示的数据行。它确保了即便多个不同的人访问的是同一个视图,他们所看到的数据内容也是经过个性化筛选的,是“千人千面”的。

  • 对于当前场景,我们只需要在条件处添加查询条件:关联账号等于某个表达式。

    f36dbc31-c182-431d-84a7-09212da5c0d1

点击上图中表达式左侧的输入框,会弹出一个表达式选择的窗口。完全理解表达式需要一点编程基础,如果您想深入了解,可以点击此链接表达式 | 织信低代码平台开发文档

或者您可以直接切换到当前窗口的上下文标签,点击第一个 Context.userId()并确定即可(记住:只需要点击一次!)。

766db9dd-b674-4193-a417-c7a0974f144d

最终我们会得到如下一个过滤器,这个过滤器只对普通员工可见,并且在这个过滤视图下,只能看到自己的数据:

image-20250927164709865

2.5.4 验证效果

完成上面的操作并发布应用后,进入应用(确保您现在登录的账号的角色是普通员工),查看员工表,可以看到不管原来员工表中有多少数据,现在只能看到关联账号是当前账号的数据。

b4529d71-f5f1-4363-b745-6743584b528f

2.6 实践四:记录级(行级)权限控制(下)

在上一小节,我们通过为用户添加组合查询条件,来实现了普通员工只能看到自己的数据。但是,如果您登录角色是主管或者 HR 的用户,您会发现您现在并不能看到其他员工的数据。这是因为我们目前只有一个普通员工可见的组合查询条件,因此,我们需要分别为部门主管和 HR 添加他们各自的组合查询条件。同时,为了实现部门主管只能查看自己部门的员工的数据这一功能,我们需要在员工表增加一个字段—部门主管(如果您在未来更加了解织信的自动化和表达式后,您可能会发现不添加此字段也能实现本功能,这也是我们织信的设计理念:为同一个业务场景,提供不同层次、不同复杂度的解决方案,以适应不同水平的用户,条条大路通罗马。)。

2.6.1 为【员工表】添加“部门主管”字段

为了能在设置权限规则时,方便地判断“某条员工记录的主管是否就是当前登录的用户”,我们需要在【员工表】中增加一个字段,用来显示该员工的部门主管。

这里我们使用一个巧妙的方法,无需手动维护数据。

  1. 进入字段设计:返回“员工信息管理系统”的应用设计界面,进入【员工表】的“表单字段”设计页。

  2. 添加“关联记录字段”

    • 点击“添加字段”,在字段类型中选择 关联记录字段

    • 字段名称:输入 部门主管

    • 源字段:这是最关键的一步。选择【员工表】中已有的 所属部门 字段。

    • 关联字段:选择后,系统会让你从【部门表】的字段中选择一个来关联显示。在这里,我们选择 部门主管 字段。

      0a2df1d7-e006-46a2-94a4-eb9d9212139f

  3. 保存字段:点击保存。

完成这一步后,你在【员工表】中会看到新增的“部门主管”一列(记得要在表格设置中添加这个显示字段!)。它的值是自动带出的,你无需手动填写。当一个员工的所属部门确定后,该部门的主管会自动显示在此处,保证了数据的一致性。

2.6.2 为【部门主管】角色添加组合查询条件

现在我们有了判断依据,可以开始为“部门主管”角色设置权限了。

配置过程和 2.5.2 小节完全一致,只需要配置如下一个过滤器即可(只筛选所在部门主管等于自己 ID 的员工):

26311e7f-fd4d-4198-b851-db7cc9c9afd8

2.6.3 为【HR 专员】角色配置“权限”

对于需要查看所有数据的“HR 专员”角色,其配置反而最简单。

和上一步操作一样,为 HR 专员新增一个仅有 HR 专员可见的过滤器,只不过在这里,我们不需要添加任何组合查询条件。一个空的条件列表,对于系统而言,就意味着“无限制”。系统不会对该角色进行任何行级数据过滤。

104142a7-4dbe-4734-aa40-07eeeaf0c2a7

2.6.4 验证效果

现在,我们为【员工表】设置了多个“组合查询条件”。系统在判断权限时的逻辑是 “或”(OR) 关系:

当一个用户访问【员工表】时,系统会逐一检查他所拥有的角色对应的所有条件组。只要他满足其中任意一个条件组的规则,他就能看到该规则筛选出的数据。

  • 如果他是普通员工,他满足“关联账号 等于 当前登录用户”的规则,所以能看到自己的记录。
  • 如果他是部门主管,他满足“部门主管 等于 当前登录用户”的规则,所以能看到自己部门所有员工的记录。
  • 如果他是HR 专员,他没有任何数据过滤规则,所以能看到全部员工的记录。

验证效果:

  1. 发布应用,确保所有权限设置都已生效。

  2. 以【普通员工】角色登录:访问【员工表】,验证是否只能看到自己那一条记录。

  3. 以【部门主管】角色登录:访问【员工表】,验证是否能看到且仅能看到自己部门下所有员工的记录。

  4. 以【HR 专员】角色登录:访问【员工表】,验证是否可以看到公司所有部门的所有员工记录。

  5. 如果一个员工身份既是普通员工、也是 HR 专员、也是部门主管的话,那么他就能看到所有的筛选条件,并可以通过切换页签的方式,来查看不同的筛选效果。

    3d5d6581-a6a6-4698-b1ad-56255d4d76e9