YetiForce模块与权限

本文目录导读：

1. YetiForce 模块 (Modules)
2. YetiForce 权限系统 (Permissions)
3. 模块与权限的交互
4. 总结与最佳实践

YetiForce 是一款基于 Vtiger 二次开发的开源 CRM 系统，但其架构和功能已经远超原版 Vtiger，在 YetiForce 中，“模块”和“权限”是其核心组成部分,管理方式既强大又精细。

下面我会从 模块架构 和 权限系统 两个维度,并结合它们的交互关系进行详细说明。

YetiForce 模块 (Modules)

YetiForce 拥有丰富的模块，分为标准模块和行业特定模块,模块是承载数据和业务流程的容器。

模块的分类

• 核心业务模块：如 Accounts (客户/公司)、Contacts (联系人)、Leads (潜在客户)、Opportunities (商机/销售机会)、Potentials (和 Opportunities 类似，早期版本用)、Products (产品)、Services (服务)、SalesOrder (销售订单)、Invoice (发票)、TroubleTickets (工单/支持单)。
• 辅助与功能模块：Project (项目管理)、ProjectMilestone (项目里程碑)、ProjectTask (项目任务)、Calendar (日历)、Documents (文档)、EmailTemplates (邮件模板)、Reports (报表)、Dashboards (仪表板)。
• YetiForce 特色/增强模块：
  • OSSMailView：邮件查看模块,集成邮件客户端。
  • OSSTimeControl：时间控制模块，用于记录工作时间、项目管理工时。
  • OutsourcedProducts：外购产品管理。
  • RecurringSalesOrders：周期性销售订单（订阅管理）。
  • Partners：合作伙伴管理。
  • Competition：竞争对手管理。
  • FBookkeeping：财务会计相关模块。
  • OCS / OSS：用于 IT 服务管理的设备/服务模块（OSService, OSDocument, OSRaid, OSNetwork等）。
  • IGIN / IGRN / IIDN：库存管理中的发货通知、收货通知、内部转移通知。
  • Assets：资产/设备管理（售出的产品成为资产）。
  • Notifications：内部通知和提醒系统。
  • Chat：内部聊天模块。

模块的核心操作与字段

• 字段类型：YetiForce 支持非常丰富的字段类型，这是其灵活性的关键，除了常规的文本、数字、日期、下拉列表等，还包括：
  • 关联字段：Related list (关联表)、Many-to-Many (多对多关系)、User (用户选择)、Owner (所属人)。
  • 高级字段：Multi-Select (多选下拉)、Country (国家)、Currency (货币)、Currency List (多币种)、Percentage (百分比)、Number (带单位)、URL、Phone、Email (可批量发送)、Picklist dependency (下拉列表层级依赖)。
  • 特殊字段：Image (图片)、Tree selector (树形选择器，适用于分类)、SMTP (邮件服务器配置)、Map (地图坐标)。
• 布局编辑器：你可以通过 CRM Settings -> Module Manager -> 选择一个模块 -> Layout Editor 来完全自定义每个模块的页面布局、字段顺序、块区（Block）的显示与隐藏。

YetiForce 权限系统 (Permissions)

YetiForce 的权限系统是其最强大的功能之一，采用 多层、多层次 的精细控制，它不再是简单的“管理员/用户”区分。

核心原则: 权限是 “角色 + 全局权限 + 配置文件 (Profiles) + 字段级访问 + 共享规则” 的组合。

角色 (Roles)

• 层次结构：角色被组织成树形结构。CEO -> VP Sales -> Sales Manager -> Sales Rep。
• 决定层级权限：高级别的角色（如 VP Sales）默认拥有查看下属（低级别角色）记录的权限（取决于配置文件设置）,低级别角色无法访问高级别角色的记录。
• 记录所有权：角色决定了“谁拥有什么级别”的记录。

全局权限 (Global Permissions)

这是一个总开关，用于定义用户是否能访问系统，主要有两种设置：Enabled 和 Disabled，以及 Admin,真正的权限控制由配置文件承担。

配置文件 (Profiles)

• 这是权限控制的核心，配置文件是权限策略的集合,一个用户有且只有一个主要配置文件。
• 配置文件的设置范围：在 Core Permissions -> Profiles 中，你可以为每个模块精确设置：
  • 操作权限：View (查看), Create (创建), Edit (编辑), Delete (删除), Import (导入), Export (导出), Assign/Change Owner (修改所属人)。
  • 记录级权限：决定用户能看到 / 编辑 / 删除哪些记录。
    • Public: All (公开：所有记录) — 能看到系统中所有用户的该模块记录。
    • Public: Own (公开：自己的) — 只能看到自己创建或分配给自己的记录。
    • Public: None (公开：无) — 不能看到任何记录 (通常用于某些模块)。
    • Private: All (私有：所有) — 自己的记录只能自己看，但需要分享规则才能被他人看到,这是非常严格的模式。
    • Private: Own (私有：自己的) — 最严格的：只看自己的记录，且不能通过分享规则被他人看到（除非被明确分配/共享）。
    • Public: Read only — 只能查看,不能编辑。
    • Public: Read/Write — 可以查看并编辑所有记录。
    • Public: Edit/Delete — 可以查看、编辑、删除所有记录。
    • Public: Manage — 自己的记录可以完全控制,其他用户的记录根据共享规则。
  • 字段级权限：在配置文件中，你可以针对每个字段设置是否可见、可编辑或必填。Salary 字段，普通销售员不可见，经理可见但不可编辑，HR 可见且可编辑。
  • 标准操作与自定义操作：还可以控制是否允许用户执行特定的标准操作（如Merge 合并, Mass Edit 批量编辑, Delete 删除）以及自定义操作按钮。

共享规则 (Sharing Rules)

• 目的：覆盖配置文件的通用记录级权限，为特定的 角色或团队 提供额外的、基于规则的访问权限。
• 例子：假设配置文件设置允许销售代表只能看到自己的Leads，你可以创建一个共享规则：“Lead 被分配给Sales Team，那么Sales Manager角色下的所有用户都可以查看并编辑此记录。” 这比在配置文件中将Leads设为Public: Own然后给经理一个单独的配置文件更灵活。
• 类型：
  • Public: 所有用户都可以查看/编辑，但可以通过规则限制为特定角色/团队。
  • Private: 只有记录的所有者可以操作,通过共享规则开放给其他人。
  • Read Only: 只有所有者可编辑,其他人只能查看。
  • Read/Write: 所有人都可以查看和编辑（通常会通过规则限制范围）。

字段级访问 (Field Level Access)

• 精细到每个字段：在配置文件中，你可以设置每个字段的权限：Visible (可见), Read Only (只读), Hidden (隐藏), Required (必填)。
• 适用场景：银行 CRM 中，PAN 或 SSN 字段对所有非特定角色不可见，经理可见只读,合规人员可见可编辑。

模块级权限 (Module Level Access in Profiles)

• 控制访问模块：你可以在配置文件中决定用户是否能访问某个模块（甚至看不到菜单项）。
• 操作权限：在模块内,再定义上述记录级和字段级权限。

行级权限（记录权限）的优先级

权限计算遵循一个严格的优先级（从高到低）：

1. 用户的角色：决定了默认的层级关系。
2. 用户的配置文件：定义了模块和字段的基本访问权限。
3. 共享规则：覆盖配置文件中的记录级访问限制。
4. 特别的权限设置：
   • Is Owner (用户本人)：对自己的记录拥有最高权限（可编辑、删除）。
   • Is Assigned To (被分配给)：记录被明确分配给你的,你拥有完整权限。
   • Is In Role Hierarchy (属于角色层级)：如果你的角色是上级,可以访问下属的某些记录。
   • Is In Team (在团队中)：如果你在某个团队中,共享规则可能允许你访问该团队内的记录。
   • Is Related (关联记录)：与你有业务关系的记录（你负责的客户的联系人）。
   • 手动共享：用户可以将自己拥有的记录主动共享给特定用户、角色或团队。

模块与权限的交互

1. 菜单可见性：模块的可见性由配置文件决定，如果在配置文件中禁用了Leads模块，那么该用户不会在菜单中看到Leads项。
2. 布局布局：字段的可见性由配置文件中的字段级权限决定，即使用户有权限访问模块,某些字段也可能被隐藏或设为只读。
3. 记录访问：用户是否能创建、查看、编辑、删除特定模块中的特定记录,由配置文件中的记录级权限和共享规则共同决定。
4. 操作限制：用户能否导出、导入、合并记录，都由配置文件决定,这些操作通常是基于模块的。
5. 仪表板和报表：用户看到的仪表板小部件和报表，受到模块权限和记录权限的限制,用户无法看到他们没有权限访问的记录。
6. 关联列表（Related Lists）：一个模块记录（如Account）下方会显示关联的模块（如Contacts, Opportunities, Documents等），用户对关联模块的访问权限（查看、编辑、创建）决定了他们在关联列表中能做什么，如果用户对Documents模块只有View权限，那么关联列表中Documents部分就只能查看,不能上传。

总结与最佳实践

• 不要直接修改默认管理员配置文件：始终创建一个或多个自定义配置文件来满足不同角色的需求。
• 设计角色层次结构：清晰的角色树形结构是权限管理的基石，CEO -> VP -> Manager -> Team Lead -> Salesperson。
• 配置文件控制“能做什么”：即创建、查看、编辑、删除、导出、导入。
• 共享规则控制“能看谁的”：即记录级访问控制，用于处理特殊情况（如跨部门协作）。
• 字段级权限用于数据安全和合规：隐藏敏感字段,确保数据只对需要的人可见。
• 测试是关键：权限设置极其复杂，为关键用户在沙箱或测试环境中设置好权限后，模拟不同角色的登录和操作,确保行为符合预期。
• 使用“权限模拟器”：YetiForce 后台提供 权限模拟器 (Permission Simulator)，可以输入一个用户 ID，查看其在特定记录上的权限,这是排查权限问题的最佳工具。

示例权限场景：

角色：Sales Manager（销售经理） > 用户 角色：Sales Manager；配置文件：Sales Manager Profile

要求：销售经理可以看到自己团队（下属）的所有销售机会（Potentials），并且可以修改其中的销售阶段；但不能看到其他团队或其他经理的数据；不能删除任何记录。

实现：

1. 配置文件 (Sales Manager Profile)：
   • 模块：Potentials -> 操作权限：View, Edit, Create, Delete (虽然我们想限制删除，但这里可以给Edit，然后通过共享规则来限制删除?)
   • 更简单的方法是：配置文件中设置 Potentials 的记录级权限为 Public: Read/Write (所有记录可编辑) 和 Public: Own (所有记录可编辑，但后续共享规则限制范围)。
   • 然后在配置文件中设置 Delete 权限为 No,直接禁止删除。
2. 共享规则：
   • 创建一个规则：针对Potentials模块。
   • 规则类型：Public (公开) 但这个公开不是对所有人都开放，而是对 Manager 角色开放。
   • 规则：如果记录属于“下属”角色中的用户，则赋予View + Edit权限给角色Sales Manager。
   • 这样，一个Sales Manager的角色用户，他的配置文件允许他查看和编辑所有记录（Public: Read/Write），但共享规则限制了“只允许编辑属于自己的和下属的记录”,这有点矛盾。

更优的简洁方案：

1. 配置文件：设置Potentials模块的记录级权限为 Public: Own (只能看到自己的) + Edit, Create 权限。Delete 设为 No。
2. 共享规则：
   • 创建一个共享规则：角色 Sales Manager (或用户组) -> 对所有下属角色（例如Sales Rep角色）中用户拥有的记录，授予 Read/Write 权限。
   • 创建第二个共享规则（如果需要）：角色Sales Manager 对自己的记录？自己的记录自动拥有所有权限（配置文件给的）。

这样，销售经理可以看到所有下属（Sales Rep）的销售机会，并能够编辑它们（因为规则给了Read/Write）；同时配置文件限制只能看到下属的记录和自己创建的；配置文件还禁止了删除功能,完美！

YetiForce 的权限系统功能强大，但学习曲线较陡，建议多使用其内置的权限模拟器进行测试，如果你有具体的权限配置场景，可以告诉我,我可以提供更详细的步骤方案。