ウォッチャーとプロジェクト通知設定者のメール宛先設定

Redmineのチケット登録/更新時のメール宛先について、デフォルトでは、ウォッチャーは「CC」、プロジェクト通知設定者※は「TO」となっている。
これらを、各々「TO/CC」から選択設定できるようにしたみた。
チケットのメール通知対象の意味付けを、システムの性格に応じて柔軟に決められるようになる。
※プロジェクト通知設定者:「個人設定」で「参加している(選択した)プロジェクトのすべての通知」を設定しているユーザー


<機能>

  • チケットのウォッチャーやプロジェクト通知設定者のメール宛先を「TO/CC」から選択設定できるようにする機能。

<Redmineでの設定>

管理→設定→メール通知 で次の項目を設定する(TO/CCを選択)。
  • チケットのウォッチャーの宛先
  • チケットのプロジェクト通知設定者の宛先

<Redmine-2.5.1 差分コード>

  • ウォッチャーとプロジェクト通知メールの宛先設定機能
    Github

ロールの利用を制限する

ユーザーとプロジェクトのアクセスレベルによってプロジェクトへのアクセス制限機能を拡張する」の記事で、ユーザーとプロジェクトにアクセスレベルを設けて、アクセスを制御する機能を紹介した。
今回は、ロールにもアクセスレベルを設けて、
  1. ユーザーが使えるロール(プロジェクト設定のメンバーでアサインできるロール)
  2. プロジェクトで有効な(利用できる)ロール
を設定できる機能を追加してみた。 なお、対象のRedmineは、2.5.1。 また、「ユーザーとプロジェクトのアクセスレベルによってプロジェクトへのアクセス制限機能を拡張する」が適用されている(ユーザーのアクセスレベル属性が追加されている)ことが前提。

<機能>

  1. ユーザーが使えるロールを設定する機能
    ユーザーへプロジェクト設定「メンバーの管理」権限を与える運用で、そのユーザーに利用させたくないロール(そのユーザーよりも強力なロール)がある場合に、ユーザーが利用できるロールをユーザーのアクセスレベルに応じて制限できるようにする機能。
    ユーザー個別に設定したアクセスレベルとロール個別に設定したアクセスレベルを比較して、ユーザーレベル未満のロールレベルのロールだけを使えるようにする仕組み。
    もちろん高レベルのロールを作らなければ良いのだが、それができない状況で「メンバーの管理」権限を一般ユーザーに任せる場合に有用となる。
  2. プロジェクトで有効なロールを設定する機能
    プロジェクトによって利用させたい/利用させたくないロールが別れる場合に、上記1だけでは対応できないため、プロジェクト毎に利用するロールを決めてしまおうという機能。
    プロジェクト毎に使えるロールを決めてしまうので、単純にプロジェクトで使わないロールを予め外すていおくことで、誤ったロールの使い方も防グことができる。

<Redmineでの設定>

  1. ユーザーが使えるロールを設定する
    ・ユーザーのアクセスレベルを設定する
    管理→ユーザー→ログイン でユーザー属性編集画面を開き、「アクセスレベル」を0~9で設定する。
    利用を制限したいユーザーを低めに設定する。
    ・ロールのアクセスレベルを設定する
    管理→ロールと権限→ロール でロール属性編集画面を開、「アクセスレベル」を0~9で設定する。
    利用を制限したいロールを高めに設定する。

    ログインユーザーのアクセスレベルより高いアクセスレベルのロールは、どんなに頑張っても、メンバー設定で割り当てることができなくなる。
  2. プロジェクトで有効なロールを設定する
    ・管理→ロールと権限 で、「ロールの選択」権限を、プロジェクトで有効なロールを設定することができるロールに付与する。
    (もちろん、メンバーの管理を移管するユーザーに割り当てるロールには、「ロールの選択」権限は付与しない。)
    ・管理→設定→「新規プロジェクトにおいてデフォルトで有効になるロール」 で新規プロジェクト作成時のデフォルト値を設定する。
    ・プロジェクトメニューの「設定」の「ロール」で、そのプロジェクトで利用するロールのチェックをONにする。

    設定したプロジェクトのメンバー設定画面では、特定のロールしか利用できなくなる。

<差分コード>

  1. ユーザーが使えるロールを設定する機能
    Github
    (DBのmigrateが必要。)
  2. プロジェクトで有効なロールを設定する機能
    Github

ユーザーとプロジェクトのアクセスレベルによってプロジェクトへのアクセス制限機能を拡張する

Non-memberユーザーの、公開プロジェクトへのアクセス制限について」の記事で、制限設定したユーザーが公開プロジェクトへアクセスできないようにする機能を紹介した。
今回は、これにより自由度を持たせて、さらに逆パターン(非公開プロジェクトへNon-Memberがアクセスできるようにする)機能を加えてみた。
なお、対象のRedmineは、2.5.1。

<機能>

  • ユーザーとプロジェクトの各々にアクセスレベルを設けて、各々のアクセスレベルに応じて、
    ・非公開プロジェクトへNon-memberでアクセスできる機能を有効にしたり、
    ・公開プロジェクトへのアクセスを制限できる機能を有効にしたり
    設定できるようにする。
  • ユーザーごと、プロジェクトごとに、アクセスレベルを変えられる(ので柔軟な運用が可能となる)
    ・例1:アクセスレベル1の非公開プロジェクトには、アクセスレベル1以上のユーザーはNon-memberでもアクセスできるように設定可能。
    ・例2:アクセスレベル2の公開プロジェクトには、アクセスレベル1以下のユーザーはアクセスできるないように設定可能。

<Redmineでの設定>

(設定はいずれもadminで)
  • DBのmigrateが必要。
  • ユーザーの編集画面で、アクセスレベルを0~9で設定する。
  • プロジェクトの編集画面で、アクセスレベルを0~9で設定する。
  • 管理-プロジェクトで、次のチェックをONにする。(OFFの場合はRedmineデフォルトの振る舞い)
    「アクセスレベルの低いユーザーが非メンバーの公開プロジェクトへアクセスできないようにする」
    →プロジェクトのアクセスレベルより低いユーザーは公開プロジェクトへのアクセスできなくなる。
    「アクセスレベルの高いユーザーが非メンバーの非公開プロジェクトへアクセスできるようにする」
    →プロジェクトのアクセスレベルより高いユーザーは非公開プロジェクトであってもNon-memberでアクセス可能になる。

<差分コード>

Github

チケット解決/終了時の日時自動記録

先日、Redmine 2.2.3 がリリースされた。
新機能の一つに、
Feature #824: Add “closed_on” issue field (storing time of last closing) & add it as a column and filter on the issue list.
があったが、私のRedmine(v.1.4系)では、以下のように実装していたので紹介しておく。(もうv.1系には新機能は実装されないだろうし)
本家のものと違って、チケットの終了ステータスだけでなく、解決ステータスでも日時をセットするようにしている。

もともと、この機能が必要だったのは、手っ取り早くバグ曲線を書くときに、(履歴ではなく)チケット自体に解決や完了の日付が入っていることが必要だったため。

<機能>

  • チケットのステータスが変更された場合に、解決時や終了時に、チケットにその日時がセットされる。
    (トリガー:チケット登録、更新、コピー先、移動、bulk更新(コピー,移動)SCM連携時)
  • CSV出力に項目(resolved_on, closed_on)を追加。
  • チケットフィルタで解決日:resolved_on, 完了日:closed_onが利用可能。

<Redmineでの設定>

  • 「管理 - チケットのステータス」の各ステータスの設定時に、
    ・「解決日」をセットするステータス → 「解決したチケット」にチェックを入れる
    ・「完了日」をセットするステータス → 「終了したチケット」にチェックを入れる

<Redmine-1.4.4からのコード修正内容>

チケットのテンプレート機能

多くのプロダクトを扱う組織では、当然Redmine上のプロジェクトも多くなる。そうなると、Redmineで管理したい項目もプロジェクトによって、いろいろ異なってくるものだ。(もちろん組織標準を決めて、プロジェクトがそれに従うという文化もあるかもしれないけど。普通はそう簡単にはいかないでしょう。)

Redmineでは、カスタムフィールドを追加し、プロジェクトごとに採用するカスタムフィールドを決めることは、比較的容易にできる。けれど、だからといっていちいち様々なプロジェクトの要望通りにカスタムフィールドを追加していたのではきりがないし、似たフィールドや、意味不明なもの、プロジェクトの気が変わって使われないものまで出てくることでしょう。

なので、カスタムフィールドは、すべてのプロジェクトで共通に使うようなものやプロジェクトデータの計測に有益なものに、本当に最小限にとどめて、それ以外はプロジェクトの必要に応じてプロジェクトの管理下で定義するのが良い落としどころとなる。

これは、チケット編集時に説明欄にテンプレートを表示する機能を付加し、かつ、そのテンプレートがプロジェクトごとにカスタマイズ可能になっていることで実現できる。


<機能>

  • プロジェクトごと、トラッカーごとに、チケット編集時に表示するテンプレートをカスタマイズできるようにする。
  • 「Tenplate-トラッカー名」の名称でカスタムフィールド(プロジェクト)がある時に、その値をそのプロジェクトのトラッカーのテンプレートとする。

<Redmineでの設定>

  • カスタムフィールド(プロジェクト)に「Tenplate-トラッカー名」の名称でカスタムフィールドを作成する。

<Redmine-1.4.4からのコード修正内容>

添付ファイルの格納先ディレクトリを年月で分割する

Redmineでは、各種添付ファイルは全てfilesディレクトリへ格納される。
詳しいこと置いといて、LINUXでは1ディレクトリに置くファイル数として実用上1万5千個くらいと、どこかで聞いたようなないような。。。
大規模に利用していると、月に千個以上ものファイルが添付されるので、ちょっと考えた方がよいかも。
バックアップやレプリケーションで、添付ファイルのディレクトリを扱うので、メンテナンス性は良いに越したことはないし。

<機能>

  • 添付ファイルをfiles/YYMM/ディレクトリに格納するようにする。

<Redmine-1.4.4からのコード修正内容>

チケットのカスタムフィールドのステータス別必須入力チェック v.1.4.4版

redmine-2.1.0がリリースされ、新機能の一つとして、「ステータス別のチケット項目の必須/リードオンリー設定」がある。
似たような機能(「チケットのカスタムフィールドをステータス別に必須入力チェックする」)について、以前、redmine-1.3.0への適用として紹介した。
redmine-1.4系では実装される予定は無いと思うので、ここで改めて紹介しておく。

redmine-2.1.0の機能との違いは次の通り。
  • Redmineシステムとしてデフォルトの設定を行い、プロジェクト毎にカスタマイズする使い方を想定。
  • プロジェクト毎に、必須項目を設定できる。
  • カスタムフィールドに対してしか設定できない。
  • リードオンリーの設定はない。
  • ロール別の設定はない。

<Redmineでの設定>

  • データベースのmigrateが必要。(rake db:migrate RAILS_ENV="production" を実行)
  • Redmineシステムとしてのデフォルト設定を行う。
    「管理」→「カスタムフィールド」
    各カスタムフィールドの編集画面の、「必須」の項目で、そのカスタムフィールドについてデフォルトで必須にするステータスにチェックを入れる。
    「すべて」をチェックすると全てのステータスで必須となり、全プロジェクトで必須となる(従来と同じ挙動)。
    「すべて」のチェックを外すと、プロジェクト毎に必須項目を設定できるようになる。
  • プロジェクトメニューの「設定」→「情報」の「必須」で、
    ステータス別に必須にするカスタムフィールドにチェックを入れる。

<Redmine-1.4.4からのコード修正内容>


プロジェクトの終了ステータス追加・リードオンリー化

Redmineのプロジェクトのステータスは有効・アーカイブ(見られなくする)、それと削除しかない。
Redmineをある程度の規模で、長期的に使っていると、終了プロジェクトの扱いに苦慮することになるでしょう。
プロジェクトが終了しても、データを振り返るケースは多いので、アーカイブの選択肢はほとんどないだろうし、削除はなおさらだ。
かといって、全て有効にしていると、見かけ有効なプロジェクトがどんどん増えていくし。
やはり、終了ステータス、もしくはリードオンリーのようなステータスがほしくなる。

そこで、次の機能を追加してみた。

  • プロジェクトのステータスに 終了を追加する。
  • プロジェクト一覧に表示するステータスを選択可能にする(表示一覧の改善・抽出含む)
  • プロジェクトセレクタに終了プロジェクトは表示させない(終了プロジェクトにアクセスするのはトップメニューのプロジェクトから)
  • プロジェクト横断表示時のチケット一覧には、終了プロジェクトのチケットは表示しない
  • プロジェクト横断表示時のチケット一覧フィルタで、プロジェクトに終了プロジェクトを表示しない
  • チケット更新時のプロジェクトフィールドの選択肢に終了プロジェクトを表示しない
  • 終了プロジェクトはリポジトリログを取得しない
  • 終了プロジェクトでログイン者から除去する権限を設定可能にする。(Redmine利用者はログインが必須で運用する前程)

なお、Redmineのチケットにある通り、redmine-2.1.0 で、ようやくプロジェクトの終了ステータスの機能が入るらしい。
終了状態のプロジェクトで有効にする権限は、ソースコード(lib/redmine.rb)で書かれており、システムで固定のようだ。
1.4系には適用されるのだろうか?

<Redmineでの設定>

  • 終了プロジェクトでログイン者から除去する権限を設定
    「管理」→「設定」→「プロジェクト」→「ステータスが終結のプロジェクトで取り除く権限」で、終了プロジェクトで取り除く権限にチェックを入れる。(デフォルトでは主に更新系のものにチェックが入っているが、必要に応じて設定する。)

<注意点>

  • Anonymousの運用は考慮していない。当方のRedmineはログインが必須になっている運用。(「管理」→「設定」→「認証」→「認証が必要」にチェック)
  • 「取り除く権限」は終了にした全プロジェクト共通。

<Redmine-1.4.4からのコード修正内容>



Redmineからのメールのfromを更新者にする

チケット更新時などに、Redmineから送信されるメールの送信元(from)は、標準では任意のアドレスを固定にすることになる。
普通は管理者のアドレスやダミーのアドレスを使うことになると思う。

ただ、Redmineでの更新のメール通知を受ける際に、送信元が管理者等のアドレスになっているよりも、実際に更新をした人になっている方が、何かと便利。
更新通知メールに直接返信する人が、必ず出てくるし。

そこで、Redmineからのメールのfromを、チケット等(ニュースとかフォーラムとかも)などの更新者に設定できるようにしてみた。

<Redmineでの設定>

「管理」→「設定」→「メール通知」
で、設定項目を次のように設定する。
  • 送信元メールアドレスデフォルトのfromのアドレスを設定する。
    (ユーザー登録時のメールやリマインダーなど、本当に更新者がないときのメールのfromに指定する、既定のアドレス)
  • 送信元(from)を更新者にするチェックを入れると、更新者がいるメールは更新者(ログインして更新した本人)のメールアドレスがfromになる。

<注意点>

  • Anonymousの運用は考慮していない。当方のRedmineはログインが必須になっている運用。
    (「管理」→「設定」→「認証」→「認証が必要」にチェック)

<コード修正内容>


対象バージョン(ロードマップ)を更新したらプロジェクトメンバーへメールするプラグイン

Redmineの対象バージョン(ロードマップ)を更新したら、そのプロジェクトのメンバーにメール送信するプラグインを作成しました。(だいぶ前に)

Githubにリポジトリを公開しています。

redmine_version_emailプラグイン
インストールはREADME.rdocを参照してください。

このプラグインは、対象バージョンを更新した際に、

  • バージョン名
  • 期限日
  • ステータス

のいずれかを変更した際に、プロジェクトメンバーへメール送信します。
Wikiとか説明とかの変更は、敢えて無視しました。
また、メールには、変更前の値も併記することで、何から何へ変更されたかが解るようにしています。

Redmineで、バージョン(ロードマップ)がとても重要な機能であることは、少しの間使ってみれば解ると思います。 バージョンはリリースや開発のイテレーションにあたるもので、プロジェクトの基本的な管理単位になるでしょう。

なので、プロジェクトメンバーへ変更を通知することは重要になるケースが多いと思います。
もっともメールではなく、他の手段で周知するケースも多いと思いますが、大規模なプロジェクトになればなるほど、末端まで周知仕切れなかったり。

これで、こっそり期限日を延ばしたりできなくなります。