tracあれこれ

かつて数多くの開発現場でプロジェクト管理の定番ツールとして活躍した「Trac」。特に、必要なツールが最初から全部入りになっているWindows向けの「Trac Lightning」や、Linux（CentOS）で手軽に構築できるパッケージは非常に便利ですよね。

しかし、いざ運用を始めると、プロジェクトに合わせて「チケットの項目（カスタムフィールド）を増やしたい！」となった段階で、絶妙な仕様やバグに悩まされることが多々あります。

今回は、そんなTracのカスタムフィールド追加にまつわる「日付（Date）型」の罠や、環境ごとの挙動の違いについて、現場のリアルな備忘録としてまとめました！

1. Trac Lightningの「壮大な日付バグ」に気をつけろ！
1. ➔ 遭遇するバグの現象
2. Linux（CentOS＋EPEL）版のTracには管理画面がない？
1. ➔ 設定ファイル（trac.ini）の手動書き換え
2. 😭 ただし、こちらにも「Date型」の壁が……
まとめ：Tracの項目カスタマイズは一癖あり

1. Trac Lightningの「壮大な日付バグ」に気をつけろ！

Windows環境に一瞬でTrac環境を構築できる「Trac Lightning」。最大のメリットは、チケットのカスタムフィールド（独自の入力項目）の追加が、設定ファイル（ini）を弄らなくても管理画面のGUIからポチポチと簡単にできる点です。

しかし、ここで「日付（Date）型」のフィールドを追加しようとすると、以下のような謎の挙動（バグ）に遭遇します。

➔ 遭遇するバグの現象

管理画面から「Date型」でフィールドを追加する。
なぜか管理画面上の一覧では、タイプが「text」と表示される。
「あれ？間違えたかな？」 と思いつつチケットの入力画面を開くと、実際にはカレンダーが出てきて日付選択ができる（内部的にはDate型として動いている）。
しかし、仕様が気になって管理画面側で再度その項目を開き、何かしらの変更を加えて「保存」をかけてしまうと、本当の地獄が始まります。
次にチケット入力画面を開いたとき、カレンダーが出なくなり、完全にただの「text（文字列入力欄）」へとダウングレードされてしまいます。

管理画面の表示の不具合（バグ）に引っ張られて、再保存時に本当に設定が上書きされてしまうという、まさに「壮大な罠」が潜んでいるので、Date型を追加した後は絶対に管理画面から触らないように注意が必要です。

2. Linux（CentOS＋EPEL）版のTracには管理画面がない？

一方、インターネット上に公開せず、ローカル環境のLinux（CentOS）でEPELリポジトリからインストールした「生のTrac」の場合、そもそも管理画面にカスタムフィールドを追加するメニュー自体が存在しません。

そのため、項目を増やしたいときは設定ファイルを直接書き換える「男のテキスト編集」が必要になります。

➔ 設定ファイル（trac.ini）の手動書き換え

/path/to/trac/conf/trac.ini を開き、末尾などに以下のような [ticket-custom] セクションを手動で追記します。

Ini, TOML

[ticket-custom]
# テスト用のカスタムフィールド例
testfield = text
testfield.label = テスト項目
testfield.value = 初期値

😭 ただし、こちらにも「Date型」の壁が……

テキストベースで trac.ini にどれだけ頑張って書いたとしても、標準の状態では「Date型」は使えず、ただのtext（文字列）扱いになってしまいます。

Pythonの easy_install 形式で入れたTracであれば、プラグイン（TracHoursPluginやDatefieldPluginなど）をコマンドで追加導入するドキュメントがネット上でいくつか見つかるのですが、CentOSのパッケージ管理（yum/EPEL）で入れている場合、依存関係や管理の都合上、外部プラグインを無理やり入れるのは躊躇してしまいますよね。

ちなみに、EPELやRemiリポジトリを覗いてみると、バージョン管理システム連携としては「Mercurialプラグイン（trac-mercurial）」などは用意されているようですが、かゆいところに手が届くカスタムフィールド系のプラグインは見当たらないのが現状です。