4. 账号、权限与用户组

在Jira与Confluence的协同体系中，权限模型并不是一张“谁能看什么”的简单名单，而是一套由用户目录、组、项目角色、空间权限、全局权限共同构成的授权链。理解这条链的关键，是先分清“身份从哪来”“权限授给谁”“在哪一层生效”这三个问题。很多团队出现“明明加了人却看不到项目”“能进空间却改不了页面”的问题，根源往往不是权限没给，而是给错了层级或对象。

一、用户来源：先确定账号由谁管理

Jira与Confluence的用户通常来自三种目录：Atlassian账户（本地账号）、外部目录同步（如LDAP/Active Directory）、以及Atlassian Access下的身份提供商（SAML/SCIM）。本地账号适合小团队快速试用；LDAP/AD同步适合已有企业目录的组织；SAML+SCIM则适合需要统一登录与自动开通/停用的中大型企业。选择哪种方式，直接决定后续“加人”是手工邀请还是目录自动同步。

需要特别注意的是：Jira与Confluence共享同一套用户目录。也就是说，在Jira中创建或同步的用户，通常也能被Confluence识别；但“能被识别”不等于“能访问内容”，访问权仍由组、角色和权限方案决定。因此，用户管理解决的是“账号是否存在”，权限管理解决的是“账号能做什么”。

二、组管理：批量授权的载体

组（Group）是权限授予中最常用的批量单位。与其逐个给用户加权限，不如把职责相同的人放进同一个组，再把权限授给组。常见分组方式包括：jira-administrators、jira-developers、jira-users、confluence-users、confluence-administrators，以及按部门或项目划分的dev-team-a、qa-team等。

组管理的核心原则是“按职责分组，不按个人分组”。例如，把“所有需要登录Jira的人”放进jira-users，把“能管理全局配置的人”放进jira-administrators。当新员工入职时，只需将其加入对应组，权限即自动继承；离职时从组中移除，权限也随之回收。这样既减少手工操作，也避免权限残留。

三、项目角色：Jira项目内的授权枢纽

Jira的权限方案并不直接绑定“用户”或“组”，而是绑定项目角色（Project Role）。项目角色是项目级别的抽象身份，例如Administrators、Developers、Users、Viewers。一个项目角色可以包含用户、组，也可以包含“当前经办人”“项目负责人”等动态条件。

这种设计的好处是：权限方案可以跨项目复用，而每个项目只需维护“谁担任什么角色”。例如，权限方案中规定“Developers角色可以编辑问题”，那么项目A把张三加入Developers，项目B把李四加入Developers，两人都获得编辑权，但彼此互不影响。项目角色因此成为Jira权限体系中最灵活的一层。

四、空间权限：Confluence的内容边界

Confluence以空间（Space）为内容容器，权限也围绕空间展开。空间权限分为空间权限（Space Permissions）和页面限制（Page Restrictions）。空间权限决定“谁能进入这个空间、谁能读、谁能写、谁能管理”；页面限制则是在空间内部对单篇页面或页面树做更细的收窄。

空间权限通常授予组，例如confluence-users可查看，dev-team-a可编辑，confluence-administrators可管理。页面限制则用于敏感内容，如薪酬方案、未发布路线图，只允许特定用户或组查看。需要强调的是：页面限制只能收窄、不能放大空间权限。如果用户没有空间查看权，即使被加入页面限制的白名单，也无法访问。

五、全局权限：平台级的总开关

全局权限（Global Permissions）位于Jira与Confluence的管理后台，控制的是“谁能登录、谁能创建项目/空间、谁拥有系统管理权”。在Jira中，典型全局权限包括Jira Users、Jira Administrators、Browse Users；在Confluence中，包括Can Use、Create Space、Confluence Administrators。全局权限通常只授予组，且应严格控制管理员组的成员数量。

全局权限与项目/空间权限的关系可以概括为：全局权限决定“能不能进平台、能不能建容器”，项目角色和空间权限决定“进了容器之后能做什么”。两者缺一不可，但层级不同，排查问题时必须逐层确认。

六、实际配置中的判断顺序

当用户反馈“看不到某个项目”时，建议按以下顺序排查：第一步，确认该用户是否在jira-users组中，即是否拥有Jira全局访问权；第二步，确认该项目使用的权限方案中，用户所属的组或用户本人是否被授予了“浏览项目”权限；第三步，确认用户是否被加入该项目的某个项目角色，且该角色在权限方案中拥有浏览权；第四步，检查问题安全级别（Issue Security Level）是否限制了该用户查看特定问题。

Confluence侧的排查顺序类似：先确认用户是否在confluence-users组中并拥有“Can Use”全局权限；再确认目标空间是否授予该用户或其所在组“查看”权限；最后检查页面限制是否把该用户排除在外。把这条顺序固化为团队内部的排障习惯，可以显著减少“权限反复调整仍无效”的情况。

七、最小权限与定期审计

权限配置的目标不是“给得越多越省事”，而是在满足协作的前提下保持最小权限。具体做法包括：管理员组只保留必要成员；项目角色优先授予组而非个人；空间权限默认只给查看，编辑权按需开放；离职或转岗时先从组中移除，再检查项目角色和空间权限是否仍有残留。

建议每季度做一次权限审计，重点检查三类对象：全局管理员组成员、拥有项目管理员角色的用户、拥有空间管理权限的组。审计时可以直接导出组员列表与项目角色成员列表进行比对，发现“个人被直接授予权限”的情况应尽量改为通过组继承，以便后续维护。

总结来看，Jira与Confluence的权限体系是一条从“身份”到“容器”再到“内容”的授权链：用户目录决定账号来源，组承担批量授权，全局权限控制平台入口，项目角色与空间权限控制具体协作范围。把这条链的每一层职责分清，再配合最小权限原则和定期审计，就能在保障协作效率的同时，把权限风险控制在可管理范围内。