TracLightning2.xからTracLightning3.0.xへのアップグレードの注意

TracLightning3.0.0からは以前のバージョンからTracとPythonがバージョンアップになっています。そのため、従来のTracLightningに上書きインストールしても正しく動作しない場合があります。基本的には、スクラッチからインストールしてください。そうは言っても新しいTracLightningへ古いプロジェクトを移行したい方も居るでしょう。そんな人のために非公式ドキュメントとしてプロジェクトのアップグレード方法を解説します。

アップデート時の注意

projectsディレクトリのバックアップを取っておいて、新しいTracをインストール後、バックアップしたprojectsディレクトリを基に戻します。
その後、Tracにアクセスした際に表示されるメッセージに基づきDBとWikiのUpgradeを行ってください。

日付フィールドについて

日付フィールドは、2.x以前はdecoratorプラグインで行っていましたが、3.0からdatepickerプラグインを利用するようになりました。
trac.iniに下記のように「フィールド名.date/date_empty」を設定してください。

[ticket-custom]
due_assign = text
due_assign.date = true
due_assign.date_empty = on
due_assign.label = 開始予定日
due_assign.order = 0
due_close = text
due_close.date = true
due_close.date_empty = on
due_close.label = 終了予定日
due_close.order = 1
complete = text
complete.label = 進捗率(%)
complete.order = 2

Subversionについて

アップグレードするとSubversionが動作しないことがあるようです。詳細は、下記のスレッドをご覧ください。

レポートについて

Trac本体の0.11から0.12へのバージョンアップに伴い、チケット関連のテーブルが仕様変更になっています。
具体的には登録日時と更新日時等(created, modified, date, time)の日時関連のカラムをミリ秒まで格納するようになりました。(参照:Microsecondtimestamps)
この影響でレポート中のSQLで日付のカラム(created, modified, date, time)をdateやstrftimeなどの日付関連の関数で変換している場合には、変換元の値を1000000で割らなければ日付関数での変換が出来なくなっています。

レポート表示の為の整形については後述する列名による表示整形で対処可能ですが、比較条件として日付を処理している場合には注意が必要です。

具体的にdate関数の場合には

0.11以前: date(time,'unixepoch','localtime')
0.12以降: date(time/1000000,'unixepoch','localtime')

とする必要があります。

strftime関数の場合にはさらに注意が必要で、直接値を割るとレポートでエラーとなってしまうため、一旦date関数で変換後に再変換を行う必要があります。

0.11以前: strftime('%Y/%m/%d', time,'unixepoch''localtime') 
0.12以降: strftime('%Y/%m/%d', date(time/1000000,'unixepoch','localtime'))

この仕様変更に伴いTracLightning3.0.0に含まれるTrac-0.12.1.ja1では、レポート機能での列名による表示整形を日本語対応しています。
列名による表示整形では列名の末尾が 時刻 で終わるカラムはtimeとして、 日付で終わるカラムは date として、 日時 で終わるカラムは datetime に、それぞれ整形されます。
列名を整形規則に合わせた場合には自動的に整形されるためSQLの関数での表示用の整形が不要になっています。
表示整形についての詳しい内容については、インストールしたTracに同梱のwiki TracReportsを参照してください。

以下執筆中。

不具合について

メニューのチケットから登録するか、ここに記述してください。