以客户为核心的权限系统设计与总结

360_go_php
301 阅读6分钟

在设计一个针对“客户作为用户负责的资源”的权限系统时，考虑到客户会涉及不同用户操作，并且客户在不同阶段有不同的需求（例如线索、资源、商机、签约等阶段的变化），系统需要具有高度的灵活性和可配置性，能够根据不同的业务需求和用户角色来精确控制访问权限。 image.png

设计目标：

  1. 动态阶段管理：客户的生命周期包括不同的阶段（如线索、资源、商机、签约等），每个阶段可能需要不同的权限控制。
  2. 用户角色与操作权限：不同用户会在不同阶段执行不同的操作，例如销售人员可能在商机阶段更新客户信息，而客户经理在签约阶段才可以执行签约操作。
  3. 资源与权限控制的细粒度设计：权限应与具体的资源类型（线索、资源、商机、签约等）和用户的操作（创建、查看、更新、删除）紧密关联。

设计架构与流程

1. 系统核心概念

为了实现精细的权限管理和动态的权限分配，需要明确以下几个核心概念：

  • 客户（Customer）：每个客户代表一个业务单位。客户的生命周期包括多个阶段（如线索、资源、商机、签约等）。
  • 用户（User）：用户是系统中的操作人员，每个用户在不同的阶段具有不同的操作权限。
  • 角色（Role）：角色是一组权限的集合，不同的角色可以在不同的阶段执行不同的操作。
  • 权限（Permission）：权限定义了用户可以对某个资源执行的操作，例如查看、更新、删除等。
  • 资源（Resource）：资源是客户生命周期中的不同数据项，如线索、资源、商机、签约等。

2. 数据模型设计

为了支持精细的权限控制和资源管理，需要设计合适的数据模型来表示客户、用户、角色、权限和资源之间的关系。

2.1 客户表（customers）
CREATE TABLE customers (
    customer_id INT PRIMARY KEY AUTO_INCREMENT,
    customer_name VARCHAR(255),
    status ENUM('prospect', 'lead', 'opportunity', 'contracted'),
    created_at TIMESTAMP,
    updated_at TIMESTAMP
);
  • status：客户的生命周期阶段，可以是潜在客户（prospect）、线索（lead）、商机（opportunity）、**签约（contracted）**等。
  • created_at 和 updated_at：客户的创建和更新时间，用于记录客户状态的变化。
2.2 用户表（users）
CREATE TABLE users (
    user_id INT PRIMARY KEY AUTO_INCREMENT,
    username VARCHAR(255),
    email VARCHAR(255),
    password VARCHAR(255),
    customer_id INT,
    role_id INT,  -- 用户角色
    status ENUM('active', 'inactive'),
    FOREIGN KEY (customer_id) REFERENCES customers(customer_id),
    FOREIGN KEY (role_id) REFERENCES roles(role_id)
);
  • role_id：用户所属角色，决定该用户在不同阶段的权限。
2.3 角色表（roles）
CREATE TABLE roles (
    role_id INT PRIMARY KEY AUTO_INCREMENT,
    role_name VARCHAR(255),
    description TEXT
);
  • role_name：角色的名称，如“销售人员”、“客户经理”等。
2.4 权限表（permissions）
CREATE TABLE permissions (
    permission_id INT PRIMARY KEY AUTO_INCREMENT,
    resource_type ENUM('lead', 'opportunity', 'contract', 'customer'),
    action ENUM('create', 'view', 'update', 'delete')
);
  • resource_type：权限控制的资源类型，例如线索（lead）、商机（opportunity）、签约（contract）等。
  • action：权限类型，如创建（create）、查看（view）、更新（update）、删除（delete）。
2.5 角色权限关系表（role_permissions）
CREATE TABLE role_permissions (
    role_id INT,
    permission_id INT,
    PRIMARY KEY (role_id, permission_id),
    FOREIGN KEY (role_id) REFERENCES roles(role_id),
    FOREIGN KEY (permission_id) REFERENCES permissions(permission_id)
);
2.6 用户角色关系表（user_roles）
CREATE TABLE user_roles (
    user_id INT,
    role_id INT,
    PRIMARY KEY (user_id, role_id),
    FOREIGN KEY (user_id) REFERENCES users(user_id),
    FOREIGN KEY (role_id) REFERENCES roles(role_id)
);

3. 权限与操作控制

3.1 客户生命周期阶段与权限控制

客户在生命周期中可能有多个阶段，如下所示：

  • 线索阶段（Lead）：客户刚开始与公司接触，用户可以对客户进行初步的联系和评估。
  • 商机阶段（Opportunity）：客户展示出明确的购买意图，用户可以进行更深入的跟踪和沟通。
  • 签约阶段（Contracted）：客户决定签约并达成交易，用户可以执行签署和合同管理等操作。

每个阶段需要对应不同的权限控制。通过这种方式，系统可以根据客户状态动态地调整可访问的资源和可执行的操作。

例如：

  • 在线索阶段，销售人员（角色为“销售人员”）可能只有create和view权限。
  • 在商机阶段，销售经理（角色为“销售经理”）可能有update和delete权限，以便能够跟进商机。
  • 在签约阶段，客户经理（角色为“客户经理”）则有签约合同的权限，可能有create（创建合同）和view（查看合同）的权限。
3.2 资源与权限的动态关联

为了适应不同阶段的权限变化，资源的权限需要动态绑定。例如，一个用户可能在“线索”阶段有查看和编辑权限，在“商机”阶段则需要更多的权限（如update、assign等）。这些权限可以通过权限表与客户生命周期的各个阶段结合。

系统可以根据以下规则动态配置权限：

  • 线索资源权限：
    • 销售人员：create，view，update
    • 销售经理：view，update，delete
    • 客户经理：view
  • 商机资源权限：
    • 销售人员：create，view，update
    • 销售经理：view，update
    • 客户经理：view
  • 签约资源权限：
    • 销售人员：view
    • 销售经理：create，view
    • 客户经理：create，view，update
3.3 权限校验流程
  1. 用户登录：用户登录时，系统会根据用户的角色、所属客户和客户的生命周期阶段加载权限配置。
  2. 权限校验：用户进行某项操作（如查看、更新某个商机）时，系统根据用户的角色、当前客户阶段及操作类型校验权限。
    • 如果该用户具有该操作权限，允许操作。
    • 如果没有权限，拒绝操作并提示用户。
3.4 资源隔离与阶段控制
  • 资源隔离：每个客户的资源应该是独立隔离的，用户只能操作与自己所属客户相关的资源。客户的状态（线索、商机、签约等）决定了哪些资源和操作是可用的。
  • 阶段控制：每个阶段的权限设置会影响用户对客户资源的操作。例如，线索阶段时只能进行基础的信息录入和查看，而商机阶段时可以进行更复杂的跟进和更新操作。

4. 实施与优化

4.1 角色与权限的灵活配置

系统应支持灵活配置角色与权限之间的映射关系，管理员可以根据业务需求和客户生命周期的变化来调整权限配置。

4.2 性能优化
  • 缓存机制：权限校验通常涉及多表联接查询，可以使用缓存（例如Redis）来存储用户的角色权限，减少每次操作时的数据库查询负担。
  • 日志审计：为了防止权限滥用和确保安全性，系统应记录每次权限变动和用户操作，便于后期审计和问题追踪。

总结

针对客户生命周期、用户角色与权限管理，权限系统需要支持精细的动态权限控制。通过清晰的资源定义和角色权限分配，以及客户生命周期阶段的考虑，系统能够根据客户状态和业务需求灵活调整权限配置，从而确保每个用户在适当的阶段执行合适的操作。

avatar
文章
阅读
粉丝