我是Trac的粉丝，当然，当我将它用于我自己的，独立的项目时，我可以给自己完全的管理权限。
如果有其他开发人员参与，或者是非常技术性的经理（或者，就此而言，某人是设计师而不是硬编码开发人员），那么他们需要能够跟上发生的事情 - 并且做一些事情，比如添加/更新票证，但不会破坏任何东西，那么权限的细粒度性质会变得更复杂一些人的需要。
您对这些人群（以及其他类似人群）使用了哪些权限？
答案 0 :(得分：3)
如果可以避免，我通常会避免向用户提供*_ADMIN权限。通过添加TICKET_EDIT_DESCRIPTION，Trac 0.11可以更轻松一些。
根据设置和文化，我将*_VIEW权限授予authenticated（已登录的所有人）或设置不严，anonymous（每个人，甚至不是登录）。
我通常会创建一个developer组，为该组授予各种权限。然后，您只需将人员添加到组中（或将组添加为用户的权限，同样的事情）。对designer，manager，tester等
管理员需要各种ROADMAP_*和MILESTONE_*权限。除非经理真的知道SQL，否则我会对REPORT_ADMIN保持谨慎。我的老板很乐意给我一份他想要的报告的电子表格示例，我会为他提供一份报告。请务必向他们指出，如果他们设置了一个自定义查询，他们可以为它添加书签 - 一切都在URL中 - 这样他们就可以使用该书签返回与当前数据完全相同的查询。
你可能想让authenticated文件并附加到门票上 - 通常不会注意到一个bug，你仍然想知道它。如果您足够锁定工作流权限，您也可以向更多人发放TICKET_MODIFY，尽管该路由会更多。
您可以信任的人可以TICKET_EDIT_DESCRIPTION，因此他们可以在忘记开始时修复错误报告格式。
如果您有首席开发人员，那么该用户可能应该TICKET_ADMIN来处理添加版本等问题。
答案 1 :(得分：2)
我通常会启用所有VIEW s，加上WIKI_CREATE，WIKI_MODIFY，TICKET_CREATE（如果使用Simple Ticket插件，则为TICKET_CREATE_SIMPLE）和{ {1}}。
对于我相信拥有更多权力的用户，我也会启用TICKET_APPEND。
对于非技术经理，我也会打开TICKET_MODIFY。对于技术经理，我可能会跳到MILESTONE_ADMIN - 但如果这太过分了，至少要添加TRAC_ADMIN。
通常情况下，我会继续给开发人员REPORT_ADMIN ...但是如果你不相信他们那么远，通过高级用户级别加上TRAC_ADMIN的上述权限可能就足够了