介绍
大家好，我是 WcaleNieWolny - Capgo的首席软件工程师。
在过去的 8 个月里，我一直在开发"组织系统"，并且截至 2023 年 4 月 14 日，我很高兴地宣布该系统已经完成了 🎉 🎊 __CAPGO_KEEP_0__经过 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 周后就开始工作。 当时，我对代码库几乎一无所知，也没有更大的想法来实现这个功能。
8个月
这导致了实现最hacky的解决方案，只支持访问应用、频道和版本。 它甚至不允许被邀请的用户访问统计数据。
然后我等待了Martin的审查。 我等待了，等待了，但没有什么真正的发生。 3个月后，我决定回到这个问题并解决所有的合并冲突。 我也决定测试，这证明是一个很好的想法。 没什么意外，hacky的解决方案完全失败了。 在那一刻，我决定修复所有的bug并编写一个详尽的E2E测试。 我不得不与非常破碎的code和过去的我做出的很多坏决定一起工作，但经过2个艰难的周，我终于让它正常工作了。
这并不意味着它是完美的。 组织的拥有者仍然有比最高被邀请用户更多的访问权限。 用户体验也相当糟糕。 被邀请的用户甚至不能看到应用统计数据、管理账单和CLI仅限上传。
尽管有那么多挑战，Martin已经审查了PR，一个星期后它被推入生产环境。
组织v2
组织系统在所有挑战中仍然运作良好。 用户正在使用它，真正推动了整个项目的进展。 然而，我仍然必须：
- 修复 行级安全
- 支持整个CLI
- 确保管理员用户有与拥有者的相同访问权限
之后 有很多讨论 与马丁一起，我们决定最好的方法是重写整个安全规则，并将所有资源的所有权转移到组织中，而不是用户。 这将使与新组织系统的集成变得更加容易，并且也会去掉大量的遗留code。
编写新的RLScode非常繁琐，但经过一周半的时间，整个迁移就准备好了。
这一次，我们决定不编写E2E测试，这意味着我们必须手动测试。经过3次非常详尽的电话会议，马丁和我最终决定推送到生产环境并希望它会顺利。
然而，它并没有… Turns out我破坏了用户注册功能，新用户无法创建账户。
在一通紧急电话后，我迅速推送了一些更改到生产环境，然后就睡了。然而，我的更改只会带来更多问题。
我醒来后发现用户有很多空的组织。这不应该发生，因为每个用户只应该有一个组织。经过一段时间的思考，我最终成功地移除了所有的重复、空的组织，除了这点之外，其他更改都比较顺利。
组织v3
即使如此，这仍然不足够。还缺少一个巨大的组件——计费。
之前只有拥有者才能管理账单。这导致了一些有趣的问题，其中用户购买了一个计划，认为他是在为组织购买。 我们快速修复了这个问题，手动解决了它，这时我们决定这个问题是不可接受的
迁移过程相对顺利。花了一周的时间，但与V1和V2相比，它确实不是那么困难 🚀
组织v4 - 未来
经过了这么多的努力，我想现在是时候专注于其他事情了 😎
It was not easy but I learned a lot and capgo has received a very nice and important feature I still have to deprecate the legacy functions, improve the webapp user experience, monitor for bugs, but there should not be any major changes to this system.
感谢您的阅读 🚀
从A继续前进，新组织系统
如果您正在使用 新组织系统 to plan dashboard and API operations, connect it with API Overview for the implementation detail in API Overview, 简介 简介中的实现细节 API 键 API 键中的实现细节 设备 设备中的实现细节 捆绑包 捆绑包中的实现细节
