私はTracのファンです。もちろん、自分の単独のプロジェクトで Trac を使用しているときは、自分自身に完全な管理者権限を与えることができます。
他の開発者が関与している場合、またはあまり技術的ではないマネージャー (または、ハードコード開発者ではなく設計者である人物) が関与している場合、何が起こっているのかについていくことができる必要があります。チケットの追加/更新のようなものですが、何かを壊す可能性はありません。その場合、パーミッションのきめ細かい性質は、誰かに何が必要かに関してもう少し複雑になります。
それらの人々のグループ（および他の同様のグループ）にどのような権限を使用していますか?
*_ADMIN私は一般的に、パーマをユーザーに付与することを回避できる場合は避けます。Trac 0.11 では、 を追加することで少し簡単になりTICKET_EDIT_DESCRIPTIONます。
セットアップと文化に応じて、(ログインしているすべての人) または緩いセットアップ(ログインしていなくても、すべての人) に*_VIEWアクセス許可を付与します。authenticatedanonymous
通常、グループを作成し、developerそのグループにさまざまな権限を付与します。次に、ユーザーをグループに追加します (または、ユーザーへのアクセス許可としてグループを追加します)。designer、manager、testerなどについても同じことを行います。
マネージャーは、さまざまな許可を必要ROADMAP_*とします。マネージャーが実際にSQLを知っていない限り、MILESTONE_*私は用心します。REPORT_ADMIN私の上司はたいてい、希望するレポートのサンプル スプレッドシートを喜んで提供してくれます。私は彼のためにレポートを作成します。必要な処理を実行するカスタム クエリをセットアップする場合は、それをブックマークできること (すべてが URL に含まれていること) を指摘してください。そのブックマークを使用して、現在のデータでまったく同じクエリに戻ることができます。
おそらく、ファイルを作成してチケットに追加したいと思うでしょうauthenticated。通常、バグに気付く人はいませんが、それでもそれについて知りたいと思うでしょう。ワークフローのアクセス許可を十分にロックダウンすると、TICKET_MODIFYより多くの人に配布できる可能性がありますが、そのルートはもう少し手間がかかります.
あなたがある程度信頼している人はおそらく許可TICKET_EDIT_DESCRIPTIONされるので、彼らが最初からやり忘れたときにバグレポートのフォーマットを修正することができます.
主任開発者がいる場合、その個々のユーザーはおそらくTICKET_ADMINバージョンの追加などに対処する必要があります。
私は通常、すべてVIEWの に加えてWIKI_CREATE、WIKI_MODIFY、TICKET_CREATE(またはTICKET_CREATE_SIMPLESimple Ticket プラグインを使用している場合) および をオンにしTICKET_APPENDます。
もう少しパワーがあると信じているユーザーのために、 もオンにしTICKET_MODIFYます。
技術者ではないマネージャーの場合は、 もオンにしMILESTONE_ADMINます。技術マネージャーの場合、私はジャンプする可能性が高いですTRAC_ADMINが、それが遠すぎる場合は、少なくとも追加してREPORT_ADMINください.
通常、私は先に進んで開発者TRAC_ADMINに権限を付与します...しかし、開発者をそれほど信頼していない場合は、パワー ユーザー レベル プラスの上記のアクセス許可TICKET_ADMINでおそらく十分です。