简介
嘿，我是 WcaleNieWolny - Capgo的首席软件工程师。
在过去的8个月里，我一直在开发 组织系统,并且截至2023年4月14日，我很高兴地宣布该系统已经完成了 🎉 🎊
经过8个月的努力，Capgo的每个部分都可以供组织成员访问。这包括
- 应用
- 统计数据
- billing
- 全方位CLI支持
- 并且还有更多!
到达这里并非易事;系统经过了3次重大修订。
组织v1
起步并不顺利…我刚加入这个项目后2周就开始工作了。 当时我对代码库几乎一无所知，也没有更大的想法来实现这个功能。
这导致了只支持访问应用、频道和版本的最hacky解决方案。 甚至不允许被邀请的用户查看统计数据。
然后我等待了Martin的审查，但什么也没发生。3个月后，我决定回到这个问题并解决所有的冲突。同时，我也决定进行测试，这个决定非常好。 毫无意外，hacky解决方案完全失败了。在那个时候，我决定修复所有的bug并编写一个全面的E2E测试。 我不得不与非常破碎的code和过去的我做出的很多坏决定一起工作，但经过2个艰难的周，我终于让它正常工作了。
这并不意味着它是完美的。组织的拥有者仍然拥有比最高被邀请用户更多的访问权限。用户体验也非常糟糕。被邀请的用户甚至无法查看应用统计数据、管理账单和CLI仅限上传。
尽管存在着这些挑战，Martin已经审查了PR，并且一周后它被推入生产环境。
组织v2
尽管面临各种挑战，组织系统仍然运作得相当好。用户正在使用它，并且它真正推动了整个项目的进展。然而，我仍然需要：
- 修复在 行级安全性方面造成的混乱
- 为整个CLI添加支持
- 确保管理员用户具有与所有者相同的访问权限
之后 与马丁进行了大量的讨论后，我们决定最好的方法是重写整个安全规则，并将所有资源的所有权转移到组织中，而不是用户。这将使与新组织系统的集成变得更加容易，并且也将去除大量的遗留__CAPGO_KEEP_0__。 编写新的RLScode非常枯燥，但经过一周半的时间，整个迁移就准备好了。
Writing the new RLS code was very tedious, but after a week and a half, the entire migration was ready.
然而，它并没有… Turns out我破坏了用户注册功能，新用户无法创建账户😅
之后，我快速打了一个紧急电话，迅速推送了一些更改到生产环境，然后就睡觉了。不幸的是，我推送的更改只会带来更多问题😰
After a quick panic call, I quickly pushed some changes into prod and went to bed. Unfortunately, my changes only created more problems 😰
醒来后，我发现用户有很多空的组织。这不是应该发生的事情，因为每个用户只应该允许一个组织。经过一些头脑风暴后，删除所有重复的空组织花了些时间，但除了那以外，变化还是比较顺利的。
组织 v3
即使如此，也不足以解决问题。还缺少一个巨大的组件——计费。
到目前为止，只有组织的创建者才能管理计费。这导致了一个有趣的问题：用户购买了一个计划，认为自己是在为组织购买的。 我们快速修复了这个问题，随后我们决定这个问题是不可接受的。
迁移过程相对顺利。花了一个星期的工作，但与 V1 和 V2 相比，它确实不是那么困难 🚀
组织 v4 - 未来
经过了这么多的努力，我想现在是时候专注于其他事情了 😎
这不是容易的，但我学到了很多，capgo 得到了一个非常棒和重要的功能 我还需要废弃旧的函数、改善 Web 应用用户体验、监控 bug 等，但这个系统应该不会有太大的变化。
感谢您的阅读 🚀
继续阅读 A brand new organization system
如果您正在使用 A brand new organization system 为了规划API面板和API操作，连接它 API概览 API概览的实施细节 介绍 介绍的实施细节 API密钥 API密钥的实施细节 设备 设备的实施细节 捆绑 捆绑的实施细节
