企业官网建设流程全解析

• 后端
• 前端
• 协同办公
• 即时通讯
• 企业应用

DooTask 主程序并未提供单一的「合规设置」菜单，而是通过数据导出、用户举报、账号删除 Hook、三级权限与私有化部署等分散能力，覆盖数据合规、用户隐私与内容审核场景。本文面向系统管理员与合规责任人，梳理这些能力的入口、配置方式与源码实现链路，并给出可落地的合规检查清单与能力边界说明，帮助你对照内部合规要求逐项自查。

核心结论：合规不是单一功能，而是一组分散能力的组合

在 resources/ai-kb/zh/concept/compliance/overview.md 中，DooTask 明确将「合规」定义为能力索引而非独立产品模块：主程序没有「合规设置」集中页面，但通过多个分散功能覆盖数据合规、用户隐私、内容审核等场景。管理员需要把分散在系统设置、团队管理、部署层的能力组合起来，才能构成一条可审计的合规链路。

以下是原文档给出的合规维度与现有手段对照表，其中「主程序入口」指向对应功能模块：

从整体设计看，DooTask 的合规策略是「能力分散、责任集中」：产品提供能力底座，合规责任由私有部署方承担。多数合规项需要管理员人工配合服务器运维（HTTPS、备份脚本）完成。

数据删除请求（GDPR 第 17 条）的完整实现链路

GDPR 第 17 条「删除权（被遗忘权）」是合规审查的重点。DooTask 通过用户生命周期 Hook 把删除事件广播给 appstore 微服务，由各插件自行清理用户数据。原文档给出的核心调用是：

Apps::dispatchUserHook($user, 'user_offboard')

对应的事件类型为event_type=delete。下面结合源码还原完整的触发链路。

触发点：UserObserver 的 deleted 事件

在 app/Observers/UserObserver.php 中，用户记录被删除时依次执行：

1. 投递 Manticore 搜索索引删除任务（ManticoreSyncTask('user_delete', ...)），保证搜索结果不再暴露已删除用户；
2. 非机器人账号触发Apps::dispatchUserHook($user, 'user_offboard', 'delete')，把删除事件推送给 appstore；
3. 调用Badge::clearByUser()清除该用户全部应用角标。

同一观察者还覆盖了「离职」场景（app/Observers/UserObserver.php）：当disable_at字段从无值变为有值（管理员操作离职）时，触发user_offboard+event_type=offboarded；反向变化（取消离职）则触发user_onboard+restore。这意味着「删除」与「离职」是两条不同的 Hook 语义，插件侧需要分别处理。

Hook 实现：Apps::dispatchUserHook

核心实现在 app/Module/Apps.php：

• 若config('app.key')为空，直接跳过并记录[appstore_hook] APP_KEY is empty日志；
• 组装用户负载：id、email、name、role（admin/normal）、tel、profession、birthday、address、introduction，以及从UserDepartment查询出的departments数组；
• 携带event_type与changed_fields字段；
• 请求 URL 固定为http://appstore/api/v1/internal/hooks/{action}，鉴权头为Authorization: Bearer md5(app.key)，附带Version头；
• 超时 5 秒，失败时记录[appstore_hook] dispatch fail日志但不阻断主流程。

user_update Hook：个人数据变更的审计补充

app/Observers/UserObserver.php 定义了需要监控并触发user_updatehook 的字段白名单：email、tel、nickname、profession、birthday、address、introduction、department。当这些字段发生变更时（app/Observers/UserObserver.php）：

• 用户自己修改 →event_type=profile_update；
• 管理员代改 →event_type=admin_update。

changed_fields数组会列出本次实际变更的字段名，供 appstore 插件决定是否需要同步清理或更新外部存储中的个人数据。

数据可携性：四类 Excel 导出与异步链路

GDPR 第 20 条「数据可携权」在 DooTask 中对应管理员数据导出功能，详见 resources/ai-kb/zh/concept/data-export/overview.md。需要明确的是：导出不是普通成员的自助功能，全部入口仅系统管理员（userIsAdmin）可见。

该功能的几个关键性质直接关系到合规审计：

• 异步生成：触发后接口立即返回，文件由 Swoole 协程后台生成（go(...)），生成完成后才推送消息；
• 机器人投递：所有导出完成消息的发送方都是system-msg系统机器人，文件经管理员私聊下发，因此在管理员与机器人的对话记录中可以追溯每次导出行为，这是当前唯一的导出审计痕迹；
• 下载链接限时：消息中的下载链接使用Down::cache_decode()解码，链接过期后文件失效，降低文件长期滞留风险；
• 范围上限：每种导出都有成员数 / 日期范围上限（通常单次 ≤ 35 天、≤ 50 个成员），具体以各子类型的提示文案为准。

需要特别提醒：主程序没有用户 / 成员列表的批量导出入口（参考 resources/ai-kb/zh/howto/data-export/user.md）。用户表含手机号、邮箱、部门等敏感字段，若确有导出全员通讯录的需求，应走 API 拉取或 DBA 直查数据库的替代方案，并在内部建立审批流程。

内容审核：举报管理后台

内容审核对应 resources/ai-kb/zh/concept/abuse-report/overview.md。任何成员在群聊 / 个人对话遇到违规消息时可提交举报，系统管理员在「举报管理」后台审核并标记处理或删除。模型为App\Models\Complaint，控制器为ComplaintController。

合规相关的关键事实：

• 举报对象是整个对话（dialog_id），不能对单条消息单独举报；
• 举报类型为固定 7 种受控词表：诈骗诱导转账（10）、引流下载其他 APP 付费（20）、敲诈勒索（30）、照片与本人不一致（40）、色情低俗（50）、频繁广告骚扰（60）、其他问题（70）；
• 举报提交后，后端取identity LIKE '%,admin,%'且按line_at倒序的前 10 位管理员，由system-msg系统机器人推送「收到新的举报信息：{原因}」；
• 举报人userid会被落库保存，不支持匿名举报；
• 举报不会自动封号或屏蔽，最终处置权在管理员；必要时可联动「团队管理 → 禁用账号」。

访问控制：三级权限体系与 LDAP

访问控制是数据合规的基础。DooTask 的权限体系（resources/ai-kb/zh/concept/role-permission/overview.md）拆成四个层级，按操作场景分别判断：

• 系统级：超级管理员（第一个注册用户 id=1）+ 系统管理员（identity 含admin），控制团队管理、LDAP、License、系统设置等；
• 项目级：项目负责人（owner=1）/ 项目管理员（owner=2）/ 项目成员（owner=0）；
• 任务级：任务负责人 / 协助人 / 可见用户（visibility），可见性独立于项目成员身份；
• 部门级：部门负责人（owner_userid）与部门管理员。

权限不会跨层级自动继承，也不存在「全局解锁所有权限」的开关，遇到「权限不足」提示时需按层级找到对应角色解决（参考 resources/ai-kb/zh/faq/role-permission/permission-denied.md）。

LDAP 集成（resources/ai-kb/zh/concept/ldap/overview.md）让企业沿用已有目录账号体系认证，实现位于 app/Ldap/LdapUser.php，依赖directorytree/ldaprecord库。关键合规点：

• LDAP 用户密码不落本地库，本地密码用随机串占位；
• 认证流程：管理员 Bind 搜索 → 取真实 DN → 「DN + 用户密码」二次 Bind → 按mail / cn / uid / userPrincipalName顺序提取邮箱 → 本地按 email 注册或合并账号；
• 只能配置 1 个 default connection，不支持多域；LDAP 用户无邮箱属性时无法完成首次登录。

数据本地化与传输加密（部署层）

这两项属于部署阶段责任，与产品功能共同构成合规闭环：

• 数据本地化：DooTask 采用全私有部署 + Docker 架构（docker-compose.yml），数据库（MariaDB）、Redis、文件存储均在自有服务器，数据不出部署方网络边界；
• 传输加密：HTTPS 需要自配 Nginx 证书。仓库根目录的管理脚本 cmd 提供./cmd https自动配置命令（内部封装bin/https install与 crontab 定时renew），也可手动配置证书；内网部署同样建议至少在出口启用加密。

此外，消息敏感通道还可叠加端到端加密：系统设置中的e2e_message开关（open/close，默认close）开启后，登录、改密、账号敏感操作、机器人接口、所有dialog/msg/*消息收发及授权信息等接口的请求体会在客户端加密后再传输，WebSocket 握手后还会用 PGP 公钥协商会话密钥（详见 resources/ai-kb/zh/howto/system-setting/e2e-encryption.md）。需要理解的是：e2e 按接口白名单生效而非按会话类型生效，未在白名单内的接口（任务、项目、文件元数据等）仍走明文 + HTTPS。

合规配置项检查清单：八步逐项落地

参考 resources/ai-kb/zh/howto/compliance/config.md，DooTask 没有集中页面，按以下分散位置逐项检查：

1. 用户协议 / 隐私政策展示：「系统设置 → 通用设置」中可配置注册时是否要求勾选《用户协议》《隐私政策》，链接为外链，需自行托管 HTML 内容（注意：后端接口api/privacy返回 HTML 页面，隐私政策入口在桌面端以页脚链接形式提供，移动端 EEUI 下在「我的 → 设置」中可见，参考 resources/ai-kb/zh/concept/user-settings/privacy.md）；
2. 注册策略：「系统设置 → 注册策略」选择「关闭注册 / 需邀请码 / 自由注册」。涉及未成年人 / 实名制场景应至少开启邀请码（reg=invite）。字段reg取值open/invite/close；reg_invite留空保存后系统会自动生成随机邀请码（用Base::generatePassword()），不能完全关闭「凭码可注册」模式；reg_identity=temp可创建受限临时账号（禁止查看共享文件、发起会话、建群、打电话、打包下载），详见 resources/ai-kb/zh/howto/system-setting/registration.md；
3. 密码强度与登录验证：「系统设置 → 安全设置」启用密码强度校验。字段password_policy只有simple（≥6 位）与complex（≥6 位且必须混合数字与字母）两档，长度上限 32 位；策略仅在设置 / 修改密码 / 注册时校验，不会强制存量用户重置，管理员需手动通知；可配套强制 2FA（如安装相关插件）。LDAP 用户由 AD 侧管控，详见 resources/ai-kb/zh/howto/system-setting/password-policy.md；
4. 内容审核：培训管理员定期查看举报管理后台，必要时联动「团队管理 → 禁用账号」；
5. 数据导出审计：管理员侧导出会经system-msg私聊推送，记录可在机器人对话中追溯（详见数据导出概览）；注意主程序没有单独的数据导出审计日志，这是当前能力边界；
6. 数据保留与销毁：写脚本定期清理web_socket_msgs、temp/临时文件；离职员工走「团队管理 → 删除」自动触发user_offboardhook。个人自助注销（POST api/users/delete/account，type=warning预检 +type=confirm执行）则调用User::deleteUser($reason)，主资料立即清除、token 全部失效，邮箱进入 30 天保护期防止身份冒认，流程详见 resources/ai-kb/zh/howto/user-account/delete.md；
7. 数据备份与本地化：使用仓库根目录的 cmd 脚本定期备份数据库（./cmd mysql backup，输出为docker/mysql/backup/{DB}_{时间戳}.sql.gz压缩文件）与 uploads，备份文件应加密存放、限制访问；
8. 传输加密：部署侧用 Nginx 配 HTTPS 证书（Let's Encrypt 等），内网部署也应启用，至少在出口。

入口汇总与责任人分工

参考 resources/ai-kb/zh/menu-map/compliance/entry.md，各合规维度的实际入口如下：

权限要求方面：产品内入口均要求userIsAdmin = true；服务器层（HTTPS / 备份）需要 root 或 docker 权限；超级管理员（id=1）默认拥有全部产品权限。

责任分工建议：

• CTO / IT：HTTPS、备份、数据本地化；
• 系统管理员：用户协议、注册策略、举报、账号管理；
• 法务：审定协议文本，监督流程。

明确的能力边界（不支持清单）

原文档同时给出了诚实的边界声明，合规建设时需要把这些「不内置」项纳入人工 / 外部方案规划：

• 主程序没有内置合规配置面板（无集中页面）；
• 没有自动数据保留策略，需要外部脚本定期清理web_socket_msgs等表与temp/临时文件；
• 没有内置数据出口审计日志（数据导出动作未单独留审计日志，只能靠机器人对话追溯）；
• 不内置 cookie 同意弹窗、隐私政策签署、DSR 工单模块，需要部署方自行接入；
• 主程序不内置 GDPR DSR 工单系统，删除请求需要管理员人工响应（走团队管理删除成员触发 Hook）；
• 注销账号没有冷静期，确认后立即生效且无产品内恢复入口，user_deletes表仅保留资料快照用于历史记录展示，不能用于恢复登录（详见 resources/ai-kb/zh/faq/user-account/delete-restore.md）。

结语：把「能力组合」变成「可执行合规方案」

综合以上内容可以看出，DooTask 的合规策略是务实且克制的：它不试图替代法务与合规体系，而是把删除权（user_offboardHook）、可携权（四类 Excel 导出）、内容审核（举报管理）、访问控制（三级权限 + LDAP）、本地化（私有部署）和传输加密（HTTPS / 端到端加密）等能力底座铺设在产品各处。管理员只需对照本文的八步检查清单与入口映射，将产品能力与人工流程（协议托管、定期脚本清理、备份加密、DSR 人工响应）结合，即可搭建一套可审计、可追溯的私有化合规方案。合规责任的最终承担者是部署方，DooTask 提供的是可组合的能力而非自动化结论。

• 后端
• 前端
• 协同办公
• 即时通讯
• 企业应用