介绍
大家好，我是 WcaleNieWolny - Capgo的首席软件工程师。
在过去的8个月里，我一直在开发"组织系统"，并且截至2023年4月14日，我很高兴地宣布该系统已经完成了 🎉 🎊 组织系统最后，经过8个月的努力，所有的__CAPGO_KEEP_0__功能都可以供组织成员使用。包括：
Finally, after 8 months, every single part of Capgo is accessible to org members. This includes:
- 统计
- 计费
- 全面的__CAPGO_KEEP_0__支持
- full CLI support
- 到达这里并不是容易的；系统经过了3次重大修订。
组织v1
开始时，情况很糟糕…当时我刚加入项目2周后就开始工作。 当时，我对代码库几乎一无所知，也没有更大的想法来实现这个功能。
组织v1
这导致了实现最hacky的解决方案，只支持访问应用程序、频道和版本。 它甚至不允许被邀请的用户访问统计数据。
然后我等待了Martin的审查。 我等待了，等待了，但没有什么真正的发生。 3个月后，我决定回到这个问题并解决所有的合并冲突。 我也决定测试，这证明是一个很好的想法。 没什么意外，hacky的解决方案完全失败了。 在那一刻，我决定修复所有的bug并编写一个广泛的E2E测试。 我不得不与非常破碎的code和过去的我做出的很多坏决定一起工作，但经过2个艰难的周，我终于使它正常工作。
这并不意味着它是完美的。 该组织的所有者仍然拥有比甚至最高被邀请的用户更多的访问权限。 用户体验也相当糟糕。 被邀请的用户甚至无法看到应用程序统计数据、管理账单和CLI仅限于上传。
尽管存在所有这些挑战，Martin已经审查了PR，并在一周后将其推入生产环境。
组织v2
组织系统在所有挑战面前仍然运作良好。 用户正在使用它，并且它真正推动了整个项目的前进。 然而，我仍然必须：
- 修复 行级安全
- 支持整个CLI
- 确保管理员用户具有与所有者相同的访问权限
之后 经过大量的讨论 与马丁一起，我们决定最好的方法是重写整个安全规则，并将所有资源的所有权转移到组织中，而不是用户。 这将使与新组织系统的集成更容易，并且也会去掉大量的遗留code。
编写新的RLScode非常繁琐，但经过一周半的时间，整个迁移就完成了。
这次，我们决定不编写E2E测试，这意味着我们必须手动测试。马丁和我一起进行了3次非常详细的电话会议，最后我们决定推送到生产环境并希望它会顺利。
然而，它并没有… Turns out我破坏了用户注册功能，新用户无法创建账户。
在紧急电话会议后，我迅速推送了一些更改到生产环境，然后就睡了。然而，我推送的更改只会带来更多问题。
我醒来后发现用户有很多空的组织。这不是应该发生的事情，因为每个用户只应该有一个组织。经过一段时间的思考，我最终成功地移除了所有的重复、空的组织，除了这个问题之外，其他更改都比较顺利。
组织v3
即使如此，这也还不够。还缺少一个巨大的组件——计费功能。
之前只有拥有者才能管理账单。这导致了一个有趣的问题：用户购买了一个计划，认为这是为组织购买的。 我们快速修复了这个问题，手动修复后，我们决定这个问题是不可接受的
迁移过程相对顺利。花了一个星期的时间，但与V1和V2相比，确实不是很难 🚀
组织v4 - 未来
经过了这么多的努力，我觉得现在是时候专注于其他事情了 😎
这不是容易的，但我学到了很多，capgo获得了一个非常重要的功能 我仍然需要废弃旧的函数，改善Web应用的用户体验，监控BUG，但这个系统应该不会有太大的变化
感谢您的阅读 🚀
从A继续前进，新组织系统
如果您正在使用 新组织系统 来规划仪表板和API操作，连接它与 API概览 查看API概览中的实施细节, 简介 简介中的实现细节 API 键 API 键中的实现细节 设备 设备中的实现细节 捆绑包 捆绑包中的实现细节
