关于gitlab的一些建议已解决悬赏5积分

我看了一下，现在我用的18.7的版本，已经不是这篇文章中介绍的逻辑了，界面也不一样是不是改过一次。目前如果该用户在禅道中有仓库访问权限，合并请求的权限，却没有关联gitlab的任何帐户，该用户是可以通过管理员帐户对gitlab惊喜那个操作的，感觉很不合理。

“对gitlab惊喜那个操作” 没看懂哈
如果咱们临时有其他的好点子，我们发产品同事评估下哈。

该用户是可以通过管理员帐户对gitlab操作的，我觉得如果这个用户所有的权限应该在gitlab的权限控制之下，如果没有关联gltlab帐户，就不应该具备操作gitlab的任何权限，如果关联了gitlab帐户，就应该和关联的gitlab权限一样，不能看的就看不到。

从开发流程，减少权限配置或者安全的纬度来看，可以按照咱们这个逻辑
如果从禅道系统后续devops 流程建设的规划来看，这样设计限制太多了。
打个比方需要在某一流程结束后代码审查，或者打包版本自动执行 gitlab 流水信的场景（某些场景接口可能拿不到谁可以触发的反馈），这样就造成还需要找匹配账号的复杂问题。

您说的可以理解，禅道和gitlab权限分开配置。目前还有个问题，就是禅道上仓库访问权限是按照权限分组来配置的，目前很多人属于同一功能权限组，比如所属部门是研发一部研发二部，都是研发权限组。但是仓库里面需要看不同的仓库，配置起来就非常困难。只能专门在建立空的权限组把他们放进去。

因为之前的逻辑是查看权限会根据gitlab的权限来分配。所以就把研发权限组全部放到仓库里面了。升级以后就不行了，不管gitlab有没有权限，都能够看到所有的仓库。建议可以通过所属部门来分组比较合理。

可以折中解决一下，一个账号多个权限取的是并集的关系，可以新建按照部门结构的权限分组，这里直接使用权限分组选择

如果几个部门都是研发的权限，没有区分的必要啊，如果按照部门分配权限，现在我们有5个开发部，每个50个人，分组以后调整权限就要改5次。

嗯，这个也算是一个方案，另外代码库一般是与禅道中的产品，项目关联的，如果用户没有添加到项目-团队的话，也可以配置用户无法访问此代码仓库

目前我们的策略是禅道上的项目是全部公开的，但是代码库需要配置权限，就只能单独在禅道上设置每一个仓库的权限。我们一个研发部有50个人，一共5个研发部。一个部门的50个人中，也是分属不同的仓库。而且没有地方查看确认这50个人是否都关联有gitlab帐户，如果把这个权限组都给了仓库权限，并且设置了可以提交合并请求，就可能导致没有关联gitlab帐户的人和不具备合并权限的人也可以提交合并请求。

确实是，这块我们反馈给产品同事看看怎么配置比较好
感觉可以接入 gitlab 的时候可以添加一个选项，是否完全沿用 gitlab 的权限体系或者 禅道权限+gitlab权限组合使用

非常感谢，之前的策略是在禅道里面把5个研发部250人的权限组全部给所有仓库，由gitlab来控制查看和操作权限。现在就只能在权限组里面增加很多权限组，比如每10个人一个仓库，就要加上25个空权限组用来控制git仓库查看权限。要不就只能一个人一个人加了。

好的，也感谢您给了我们这么多的建议，已经反馈内部产品同事，反馈 id：5121

还有一个问题，就是现在gitlab合并请求审核指派在禅道上没有提示了，如果仓库很多的话只有一个个点进去看才能看到。最早的版本是有一个统一显示所有合并请求的地方的。

这里我们记录下需求，感谢反馈。