与 Blue 工程团队一起深入了解他们如何构建一个 AI 驱动的自动分类和标记功能。
有效的项目和流程管理对各类组织至关重要。
在 Blue，我们已将组织世界的工作作为我们的使命，通过构建全球最佳的项目管理平台——简单、强大、灵活且对所有人都负担得起。
这意味着我们的平台必须适应每个团队的独特需求。今天，我们很高兴揭开我们最强大功能之一的面纱：自定义权限。
项目管理工具是现代工作流程的支柱，存储着敏感数据、关键通信和战略计划。因此，精细控制对这些信息的访问不仅仅是一种奢侈——而是一种必要。
自定义权限在 B2B SaaS 平台中发挥着关键作用，特别是在项目管理工具中，协作与安全之间的平衡可能决定一个项目的成功与否。
但在这里，Blue 采取了不同的做法：我们相信企业级功能不应仅限于企业规模的预算。
在一个 AI 使小团队能够以空前规模运作的时代，为什么强大的安全性和定制化应该遥不可及？
在这次幕后探讨中，我们将探讨如何开发我们的自定义权限功能，挑战 SaaS 定价层的现状，为各类企业带来强大而灵活的安全选项。
无论您是拥有大梦想的初创公司，还是希望优化流程的成熟企业，自定义权限都可以启用您从未想过的新用例。
理解自定义用户权限
在我们深入探讨为 Blue 开发自定义权限的旅程之前，让我们先了解一下什么是自定义用户权限，以及它们在项目管理软件中为何如此重要。
自定义用户权限是指为软件系统内的单个用户或用户组量身定制访问权限的能力。与依赖具有固定权限集的预定义角色不同，自定义权限允许管理员创建高度特定的访问配置文件，完美契合其组织的结构和工作流程需求。
在像 Blue 这样的项目管理软件中，自定义权限包括：
- 细粒度访问控制：确定谁可以查看、编辑或删除特定类型的项目数据。
- 基于功能的限制：为特定用户或团队启用或禁用某些功能。
- 数据敏感性级别：为项目中的敏感信息设置不同的访问级别。
- 特定工作流程的权限：将用户能力与项目工作流程的特定阶段或方面对齐。
自定义权限在项目管理中的重要性不容小觑：
- 增强安全性：通过仅提供用户所需的访问权限，降低数据泄露或未经授权更改的风险。
- 改善合规性：自定义权限通过控制数据访问帮助组织满足行业特定的监管要求。
- 简化协作：当每个成员拥有执行其角色所需的正确访问级别时，团队可以更高效地工作，而无需不必要的限制或过多的特权。
- 为复杂组织提供灵活性：随着公司成长和发展，自定义权限使软件能够适应不断变化的组织结构和流程。
达成“是”
我们之前写过，Blue 中的每个功能在我们决定构建之前都必须是一个坚定的“是”。我们没有成百上千的工程师，也没有时间和金钱去构建客户不需要的东西。
因此，在 Blue 实施自定义权限的道路并不是一帆风顺。像许多强大的功能一样，它始于用户的明确需求，并通过仔细的考虑和规划而演变。
多年来，我们的客户一直在请求对用户权限进行更细粒度的控制。随着各类组织开始处理越来越复杂和敏感的项目，我们的标准基于角色的访问控制的局限性变得显而易见。
与外部客户合作的小型初创公司、拥有复杂审批流程的中型公司，以及有严格合规要求的大型企业都表达了同样的需求：
在管理用户访问方面需要更多的灵活性。
尽管需求明确，我们最初还是犹豫是否深入开发自定义权限。
为什么？
我们理解其中的复杂性！
自定义权限涉及项目管理系统的每个部分，从用户界面到数据库结构。我们知道实施此功能将需要对我们的核心架构进行重大更改，并仔细考虑性能影响。
在我们调查市场时，我们注意到很少有竞争对手尝试实施像客户所要求的那样强大的自定义权限引擎。那些尝试的通常将其保留给最高级别的企业计划。
显而易见的原因是：开发工作量巨大，风险也很高。
不正确地实施自定义权限可能会引入关键错误或安全漏洞，可能会危及整个系统。这一认识强调了我们所考虑挑战的重大性。
挑战现状
然而，随着我们的不断成长和发展，我们达成了一个关键的认识：
在当今商业环境中，将强大功能保留给企业客户的传统 SaaS 模型不再合理。
在 2024 年，借助 AI 和先进工具，小团队可以以与更大组织相媲美的规模和复杂性运作。一个初创公司可能在多个国家处理敏感客户数据。一个小型营销机构可能在处理数十个具有不同保密要求的客户项目。这些企业需要与任何大型企业相同级别的安全性和定制化。
我们问自己：为什么公司的员工规模或预算应该决定他们保护数据和提高流程效率的能力？
企业级功能面向所有人
这一认识使我们形成了一个核心理念，这一理念现在驱动着 Blue 的大部分开发：企业级功能应该对各类企业开放。
我们相信：
- 安全不应是一种奢侈。 每家公司，无论大小，都应拥有保护其数据和流程的工具。
- 灵活性推动创新。 通过为所有用户提供强大的工具，我们使他们能够创建推动行业前进的工作流程和系统。
- 增长不应需要平台更改。 随着客户的成长，他们的工具应无缝地与他们一起成长。
怀着这种心态，我们决定直面自定义权限的挑战，致力于让所有用户都能使用，而不仅仅是那些在高层计划上的用户。
这一决定使我们走上了仔细设计、迭代开发和持续用户反馈的道路，最终导致了我们今天自豪地提供的自定义权限功能。
在接下来的部分中，我们将深入探讨我们如何设计和开发这一复杂功能以使其成为现实。
设计与开发
当我们决定处理自定义权限时，我们很快意识到我们面临着一项庞大的任务。
乍一看，“自定义权限”可能听起来简单，但它是一个复杂的功能，涉及我们系统的各个方面。
挑战是巨大的：我们需要实施级联权限，允许即时编辑，进行重大数据库架构更改，并确保在我们的整个生态系统中实现无缝功能——包括网页、Mac、Windows、iOS 和 Android 应用程序，以及我们的 API 和 Webhook。
这种复杂性足以让即使是最有经验的开发人员也停下脚步。
我们的方法集中在两个关键原则上：
- 将功能分解为可管理的版本
- 采用增量发布。
面对全面自定义权限的复杂性，我们问自己一个关键问题：
这个功能的最简单的第一版本是什么？
这种方法与敏捷原则相一致，即交付最小可行产品（MVP）并根据反馈进行迭代。
我们的答案是令人耳目一新的简单：
- 引入一个切换按钮以隐藏项目活动标签
- 添加另一个切换按钮以隐藏表单标签
就这样。
没有花哨的功能，没有复杂的权限矩阵——只有两个简单的开关。
虽然乍一看可能显得平淡无奇，但这种方法提供了几个显著的优势：
- 快速实施：这些简单的切换按钮可以快速开发和测试，使我们能够迅速将自定义权限的基本版本交到用户手中。
- 明确的用户价值：即使只有这两个选项，我们也提供了切实的价值。有些团队可能希望将活动记录从客户那里隐藏，而其他团队可能需要限制某些用户组对表单的访问。
- 增长的基础：这个简单的开始为更复杂的权限奠定了基础。它使我们能够在不一开始就陷入复杂性的情况下建立自定义权限的基本基础设施。
- 用户反馈：通过发布这个简单版本，我们可以收集用户如何与自定义权限互动的真实反馈，从而为未来的发展提供信息。
- 技术学习：这一初步实施使我们的开发团队在修改平台上的权限方面获得了实际经验，为更复杂的迭代做好准备。
你知道，拥有一个宏伟的愿景，然后发布一个仅占那个愿景小部分的东西，实际上是非常谦卑的。
在发布这两个切换按钮后，我们决定处理更复杂的功能。我们确定了两个新的自定义用户角色权限。
第一个是限制用户仅查看已被特别分配给他们的记录。如果您在一个项目中有客户，并且您只希望他们看到特定分配给他们的记录，而不是您为他们处理的所有内容，这非常有用。
第二个是项目管理员可以阻止用户组邀请其他用户的选项。如果您有一个敏感项目，您希望确保其保持在“需要查看”的基础上，这非常好。
一旦我们发布了这个功能，我们获得了更多的信心，在我们的第三个版本中，我们处理了列级权限，这意味着能够决定特定用户组可以查看或编辑哪些自定义字段。
这非常强大。想象一下，您有一个 CRM 项目，其中的数据不仅与客户将支付的金额相关，还与您的成本和利润率相关。您可能不希望初级员工看到成本字段和项目利润公式字段，而自定义权限允许您锁定这些字段，使其不被显示。
接下来，我们转向创建基于列表的权限，项目管理员可以决定某个用户组是否可以查看、编辑和删除特定列表。如果他们隐藏一个列表，该列表中的所有记录也会被隐藏，这很好，因为这意味着您可以将流程的某些部分隐藏起来，以免让团队成员或客户看到。
这是最终结果：
技术考虑
Blue 的技术架构的核心是 GraphQL，这一关键选择显著影响了我们实现复杂功能（如自定义权限）的能力。但在深入细节之前，让我们先回顾一下什么是 GraphQL，以及它与更传统的 REST API 方法的不同之处。
GraphQL 与 REST API：一个易于理解的解释
想象一下您在一家餐厅。使用 REST API，就像从固定菜单中点餐。您要求特定的菜肴（端点），然后您得到与之相关的所有内容，无论您是否想要。如果您想自定义您的餐点，您可能需要进行多次点单（API 调用）或要求特别准备的菜肴（自定义端点）。
而 GraphQL 则像是与一位可以准备任何菜肴的厨师对话。您告诉厨师您想要的确切配料（数据字段）及其数量。然后，厨师准备出正好是您所要求的菜肴——不多也不少。这基本上就是 GraphQL 的功能——它允许客户端准确请求所需的数据，服务器只提供这些数据。
一次重要的午餐
在 Blue 初始开发大约六周后，我们的首席工程师和首席执行官外出吃午餐。
讨论的话题？
是否要从 REST API 切换到 GraphQL。这不是一个轻松的决定——采用 GraphQL 意味着要放弃六周的初步工作。
在回办公室的路上，首席执行官向首席工程师提出了一个关键问题：“五年后我们会后悔不这样做吗？”
答案变得明确：GraphQL 是前进的方向。
我们早期就认识到这种技术的潜力，看到它如何支持我们对灵活、强大的项目管理平台的愿景。
我们在采用 GraphQL 时的前瞻性在实施自定义权限时得到了回报。使用 REST API，我们将需要为每种可能的自定义权限配置创建不同的端点——这种方法很快会变得繁琐且难以维护。
然而，GraphQL 允许我们动态处理自定义权限。它的工作原理如下：
- 即时权限检查：当客户端发出请求时，我们的 GraphQL 服务器可以直接从数据库检查用户的权限。
- 精确的数据检索：根据这些权限，GraphQL 仅返回符合用户访问权的数据。
- 灵活的查询：随着权限的变化，我们不需要创建新的端点或更改现有端点。相同的 GraphQL 查询可以适应不同的权限设置。
- 高效的数据获取：GraphQL 允许客户端准确请求所需的数据。这意味着我们不会过度获取数据，从而可能暴露用户不应访问的信息。
这种灵活性对像自定义权限这样复杂的功能至关重要。它使我们能够提供细粒度控制，而不牺牲性能或可维护性。
挑战
在 Blue 实施自定义权限带来了许多挑战，每一个挑战都推动我们创新和完善我们的做法。性能优化迅速成为一个关键问题。随着我们添加更多细粒度的权限检查，我们面临着减慢系统速度的风险，尤其是对于具有许多用户和复杂权限设置的大型项目。为了解决这个问题，我们实施了多层缓存策略，优化了数据库查询，并利用 GraphQL 仅请求必要数据的能力。这种方法使我们能够在项目扩展和权限复杂性增加的情况下保持快速响应时间。
自定义权限的用户界面呈现了另一个重大障碍。我们需要使界面对管理员直观且易于管理，即使在我们添加更多选项并增加系统复杂性的情况下。
我们的解决方案涉及多轮用户测试和迭代设计。
我们引入了一个可视化权限矩阵，使管理员能够快速查看和修改不同角色和项目区域的权限。
确保跨平台一致性也提出了自己的挑战。我们需要在我们的网页、桌面和移动应用程序中统一实施自定义权限，每个平台都有其独特的界面和用户体验考虑。这对于我们的移动应用程序尤其棘手，因为它们必须根据用户的权限动态隐藏和显示功能。我们通过将权限逻辑集中在 API 层来解决这个问题，确保所有平台接收一致的权限数据。
然后，我们开发了一个灵活的 UI 框架，可以实时适应这些权限变化，无论使用哪个平台都能提供无缝体验。
用户教育和采用是我们自定义权限旅程中的最后一个障碍。引入如此强大的功能意味着我们需要帮助用户理解并有效利用自定义权限。
我们最初将自定义权限推出给我们用户基础中的一部分，仔细监控他们的体验并收集见解。这种方法使我们能够根据真实使用情况完善该功能和我们的教育材料，然后再向整个用户基础推出。
分阶段推出证明是无价的，帮助我们识别和解决一些我们未曾预料的小问题和用户困惑，最终为所有用户提供了更精致和用户友好的功能。
这种向用户子集推出的方式，以及我们通常为公共测试版设定的 2-3 周“测试”期，帮助我们安心入睡。 :)
展望未来
与所有功能一样，没有什么是永远*“完成”*的。
我们对自定义权限功能的长期愿景涵盖标签、自定义字段过滤器、可定制的项目导航和评论控制。
让我们深入探讨每个方面。
标签权限
我们认为能够根据记录是否具有一个或多个标签来创建权限将是非常棒的。最明显的用例是您创建一个名为“客户”的自定义用户角色，并仅允许该角色中的用户查看带有“客户”标签的记录。
这让您一目了然地查看记录是否可以被您的客户看到。
如果能够使用 AND/OR 组合器来指定更复杂的规则，这将变得更加强大。例如，您可以设置一个规则，允许访问同时标记为“客户”和“公开”的记录，或者标记为“内部”或“机密”的记录。这种灵活性将允许极其细致的权限设置，适应甚至最复杂的组织结构和工作流程。
潜在的应用非常广泛。项目经理可以轻松隔离敏感信息，销售团队可以自动访问相关客户数据，外部协作者可以无缝集成到项目的特定部分，而不会冒着暴露敏感内部信息的风险。
自定义字段过滤器
我们对自定义字段过滤器的愿景代表了细粒度访问控制的重大飞跃。此功能将使项目管理员能够根据自定义字段的值定义特定用户组可以查看哪些记录。这是关于为信息访问创建动态、数据驱动的边界。
想象一下能够设置这样的权限：
- 仅显示“项目状态”下拉菜单设置为“公开”的记录
- 限制可见性为“部门”多选字段包含“市场营销”的项目
- 允许访问“优先级”复选框被选中的任务
- 显示“预算”数字字段高于某个阈值的项目
可定制的项目导航
这只是我们已经拥有的切换按钮的扩展。我们希望将其扩展到项目导航的每一个部分，而不仅仅是“活动”和“表单”的切换按钮。这样，项目管理员可以创建专注的界面，并删除他们不需要的工具。
评论控制
未来，我们希望在允许客户决定谁可以看到评论方面发挥创造力。我们可能会允许在一个记录下有多个选项卡式的评论区域，每个区域可以对不同的用户组可见或不可见。
此外，我们还可能允许一个功能，仅显示用户特定提到的评论，而不显示其他评论。这将允许在项目中有客户的团队确保只有他们希望客户看到的评论是可见的。
结论
所以我们就这样，介绍了我们构建最有趣和强大功能之一的方法！正如您在我们的项目管理比较工具中所看到的，很少有项目管理系统拥有如此强大的权限矩阵设置，而那些拥有的通常将其保留给最昂贵的企业计划，使其对典型的小型或中型公司来说不可及。
在 Blue，您可以使用我们计划中的所有功能——我们不相信企业级功能应该仅限于企业客户！