Jason Song

This is currently by design. But it looks like an interesting scenario to discuss.

目前的设计是权限细粒度控制，所以同一个token如果需要管理多个app的话，需要多次授权。

创建app接口需要考虑一下如何授权，因为目前的权限都是在app或namespace上

这个倒是可以考虑优化一下，有啥建议吗？

@hanyidreamer 这个实现挺好，apollo之前只有权限的管理，没有角色的管理，可以定义几个角色，或者也可以让用户自己定义角色并设置应有的权限，这样只要把人和角色关联起来就能实现后续的自动授权。欢迎PR！

Good point! 大家可以先就这个问题提出一些自己的建议哈~

> 1: 项目团队负责人，可以自由搜索配置的value，想看哪些项目在使用这个配置，比如我们有10个rds， 大概有3-5个项目要公用1个rds，某个rds需要升级的时候， 我们要看看 哪些服务会有影响。 以便通知对应的服务负责人。 这个可以通过公共 namespace 的实例列表来看到哪些服务会有影响？

在 ApolloConfigDB.Audit 表里面有所有资源操作的审计日志的（Apollo项目，集群，Namespace的创建和删除） 管理员授权这个不涉及资源，目前没有审计，不过在记录上都是有操作人信息的 这部分审计信息一般用户不会看的，所以没有通过页面透出，如果在管理员界面中增加一个应该也可以，不过这个场景能描述下吗？比如用户是谁，在什么场景下会看？

Sounds good.

open api 应该是可以的，clusterName 传灰度的 branch name