→ [trac] ワークフローをまわすとき「承認日」が欲しい。なんてな。

旧来の稟議書には必ず入ってるので、それをそのままtracに移行する場合「承認日」「承認者」とかいうフィールドを用意して解決しよう、ということになりがち*1。 すると、「クローズする際は、承認日フィールドに現在の日時を、承認者フィールドに自分の名前を入れてクローズボタンを押す」とかいうルールで運用されることになる。ワークフローシステムをつかえばこのへんは自動的にできるのに、チケットシステムだと泥臭い運用になってしまう。 こんなの絶対おかしいよ。
そこで、tracが持っている「ステータスを変えた日時」を取り出して使おう。SQLはこんなかんじ:

SELECT ticket, max(time) FROM ticket_change
    WHERE
        field = 'status' AND
        newvalue = "closed"
    GROUP BY ticket;

closed以外でも使えるように条件からはずして、tracのレポートから使えるようにビューにしておく:

CREATE VIEW status_change AS
    SELECT ticket, author, newvalue AS status, max(time) AS time
        FROM ticket_change WHERE field = 'status'
        GROUP BY ticket, newvalue;

これで、tracのレポートで以下のように使えるようになる:

select id, summary, ticket.time,
    a.time as Accepted_Date,
    c.time as Closed_Date, c.author as Closer
from ticket
left join status_change AS a on (a.ticket = ticket.id and a.status = "accepted")
left join status_change AS c on (c.ticket = ticket.id and c.status = "closed")

→ [trac] 日付の表示が変。数字になっちゃう。

オリジナルのTracを使う場合、チケットの作成日などの日付フィールドは、date, time, datetime, created, modified といった特定のカラム名の場合だけ 日付文字列(YYYY-MM-DDなど)で表示され、それ以外は unixtimeである整数値(16桁の数値)で表示されてしまうという問題がある。具体的には、tracのレポートで、チケットの作成日を created 以外のカラム名で表示しようとした際に、16桁の数字で表示されてしまう。

ネットを検索してみると、SQLiteのdatetime関数で日付文字列に変換する処理を入れる、というやり方が見つかった。こんなかんじ:

select id, summary, ticket.time,
    datetime(a.time/1e6,'unixepoch') as Accepted_Date,
    datetime(c.time/1e6,'unixepoch') as Closed_Date, c.author as Closer
from ticket
left join status_change AS a on (a.ticket = ticket.id and a.status = "accepted")
left join status_change AS c on (c.ticket = ticket.id and c.status = "closed")

まぁこれでもいいのだけど、以下の二つの点でいけてない:

1. tracではユーザごとにタイムゾーンを設定できるので、ユーザのタイムゾーンとサーバのタイムゾーンが異なるとき、「チケット作成日はユーザのタイムゾーンでの時刻表示、それ以外はサーバのタイムゾーンでの時刻表示」とかいう、変な状態になってしまう。
2. datetime関数はSQLite固有なので、バックエンドDBにMySQLを使う場合はfrom_unixtimeを使うように、PostgreSQLならSELECT TIMESTAMP WITH TIME ZONE 'epoch' + 982384720.12 * INTERVAL '1 second';というように書き換える必要がある。

→ ならば、Genshiが createdカラムを日付文字列に変換する処理を流用してみよう

Genshiが日付文字列に変換する処理そのものはユーザのタイムゾーンを意識した変換をしてくれるのだが、残念ながら「どのカラムを対象とするか」がTracに含まれるGenshiテンプレートでハードコードされている*1。このファイルをどうにか差し替えてやることで、closed.date なども、ユーザのタイムゾーンを意識した変換ができるはず。

そこで、ITemplateProviderインタフェースを実装したプラグインを作って、ちょっと改造したテンプレートを同じ名前でをプラグイン側から提供するようにしてみたところ、あっさり report_view.html を差し替えることができた。

→ genshiテンプレートの優先順位

同じ名前のテンプレートを提供するプラグインが複数あったら、そっちに負ける可能性があるよね。そこで、tracにおいてgenshiテンプレートがどういう順番で読まれるのか。tracdをデバッガで追いかけてみたところ、優先順位は以下のようになっていた:

1. プロジェクト固有のtemplatesフォルダ
2. trac.ini の [inherit]templates_dirで指定したフォルダ
3. trac本体の/trac/templatesフォルダ
4. プラグインが提供するテンプレートフォルダ。
   1. プラグイン間の優先順位はエントリポイント名順。
   2. プラグイン内の優先順位はインポート順、定義順。

つまり。trac本体の/trac/ticket/templates/フォルダはtrac.ticket.web_ui.TicketModule が提供しているので、アルファベット順で若い名前のプラグインが提供しているテンプレートが優先されることになる。今回差し替えたかった report_view.html は /trac/ticket/templates にあったので、プラグインで割り込むことができた。

→ テンプレートを置き換えるんじゃなくて、動的に書き換えることを考える。

次に考えることのメモ。ITemplateStreamFilterを使えばいいんじゃないか。これも、同じURLをどういう順番でフィルタすることになるかを考える必要がある。でも py:when の test= を書き換えるのはむずかしいかもなぁ。

→ 続きはこちら。

奮闘編

解決編