dootask/resources/ai-kb/zh/concept/micro-app/permission.md

id, title, type, feature, scope, locale, aliases, related_tools, related_pages, prerequisites, negative, last_verified

id	title	type	feature	scope	locale	aliases	related_tools	related_pages	prerequisites	negative	last_verified
micro-app.permission.concept	微应用权限	concept	micro-app	end-user	zh	微应用权限 谁能用微应用 微应用对谁可见 微应用登录态 微应用 SSO 微应用 token		application		没有「整体禁用所有微应用」的开关，按单个插件 / 单条菜单控制 微应用内部的细粒度权限（如「谁能改 OKR」）由插件自身实现，不归 DooTask 主程序管 临时帐号 / 受限身份的功能限制对微应用同样生效（如禁止创建群、禁止文件分享）	v1.7.90

微应用权限

定义

微应用权限分两层：主程序层控制谁能看到 / 进入这个微应用；插件内部控制进入后能做什么。前者由 DooTask 主程序按用户身份 + 菜单配置过滤，后者由每个插件自行实现。

主程序层判断

• 可见范围 visible_to：菜单注册时声明
  • all — 所有成员可见
  • admin — 仅系统管理员可见（应用中心走「管理员」分区）
• 管理员判断：基于 userIsAdmin，对应 User::isAdmin()
• 菜单位置 location：决定渲染在哪里（应用中心 / 主导航 / 管理员区）
• 临时帐号限制：受限身份在主程序的所有限制（禁止创建群、禁止文件分享等）同样作用于微应用调用主程序接口

登录态传递

• 微应用通过 URL ?token={user_token} 拿到当前用户身份
• 微应用自己再调用 DooTask 后端时携带该 token
• 后端会校验 token 关联的用户身份，决定是否放行接口

插件内部权限

• 由插件自行实现，DooTask 不强制规范
• 比如 OKR 内部有「目标负责人」「KR 协作者」概念
• 比如 approve 内部有「审批人」「抄送人」「发起人」概念
• 主程序对此不做拦截，只负责把用户身份传过去

与系统应用对比

• 系统应用走主程序权限体系，由 role-permission.permission-denied.faq 覆盖
• 微应用主程序层只控可见性，业务权限由插件自管