Tracのチケットに時間を入れる
目前の課題はともかく、今後のことを考えるとやっぱ時間の計測は必要だなと思ったので、以下を参考にとりあえず数字を入れる場所を用意することにした。 TracTicketsCustomFields – The Trac Project 入れるだけなら以下のような記述を conf/trac.ini に書けばイケる。 [ticket-custom] time_actual = text time_actual.format = text time_actual.label = 消費時間(h) time_expect = text time_expect.format = text time_expect.label = 予想時間(h) これで ticket の末尾に予想時間、消費時間がいい感じに追加される。期待通りに「予想時間」の方が「消費時間」よりも前に出てくる感じになるんだけど、なぜ
TracのXMLRPCを拡張してみる - いつまでもとりあえず
レポートの登録までできるようになったので，いろいろなレポートをつくろうということで，ガントチャートの作成時の効率化や，バーンダウンチャートを作成するためにTracを拡張してみました．そのメモです． やるべきことは 1. IXMLRPCHandlerをインプリしたクラスを作る XMLRPCプラグインのticket.pyとWorklogプラグインのxmlrpc.pyを参照 2. xmlrpc_methodsにメソッドを追加と必要なメソッド追加 (マップ型の)リストを返す，引数がチケット番号(int)のgetWorkHoursメソッドを追加するために次のようにしてメソッドを追加する． def __init__(self): pass def xmlrpc_namespace(self): return 'dependency' def xmlrpc_methods(self): yield ('
ProtectedMacro で !protected 部分の表示に WIKI_MODIFY を必須にするパッチ - miauのブログ
今のプロジェクトで使っている Trac は、anonymous にすべての VIEW 権限を与えています。社内のプロジェクト間でノウハウを共有できるようにこのような形にしているのですが、サーバのログインパスワード等はプロジェクト外の人には知られたくありません。 このような場合に使えそうなマクロを探してみると、ProtectedMacro と AccessMacro というものが見つかりました。それぞれ Wiki の一部の領域に閲覧制限をかけることができるプラグインですが、 ProtectedMacro のほうは unauthorized user 向きのメッセージが設定できる AccessMacro のほうはパーミッションをより詳細に設定できるが、今回ここまでの機能は必要ない ということで、ProtectedMacro のほうを試してみました。 インストール 普通にインストールできます。一
Trac のプラグインテンプレートを作るアプリを作ってみた - Natural Software
追記 アップデートしたよ Trac プラグインのテンプレートを作るのが、めんどっちかったのでプラグインテンプレートを作るアプリを作ってみた パッケージ TracPluginTemplateMaker - Shibuya.trac - OSDN ソースも置いときました http://sourceforge.jp/projects/shibuya-trac/svn/view/contrib/TracPluginTemplateMaker/?root=shibuya-trac 画面 こんなのができる 出力されたプラグインをインストールするとこのサンプルと同じような画面ができる。 今の機能 プラグインテンプレートの生成 プラグイン情報の設定 今後の予定 インタフェースの選択 （できれば）Eclipse のプラグインにしたい。。。 インストールとアンインストール インストール ここから ZIP ファ
TracWiki の h1、h2、h3 を目立たせる - miauのブログ
Trac の Wiki はデフォルトのデザインだと h1、h2、h3 の区別がつきにくくて困ります。さらに h3 ただの太字みたいに表示されるから、 === hoge ===みたいに書くべき見出し項目をただの太字 '''hoge'''で書いちゃうような人もいたりとか。それじゃ [[PageOutline]]とか使っても見出し一覧が見れなくて不便だってば。 ということで、ちゃんと構造化された TracWiki を流行らせるべく、私が使っている h1〜h3 を目立たせる CSS をさらしておきます。 適用するとどうなるの？ 変更前は こんなだったのが、変更後は こうなります。 PukiWiki の CSS を元にしつつ、さらに h1〜h3 の見分けがつきやすいようにラベル部分の色＆サイズを調整しています。 適用方法 Trac 0.11 での例です。 まず、TracInterfaceCustom
TracTicketDepgraphPlugin – Trac Hacks - Plugins Macros etc.
Ticket dependency graph Description This plugin integrates dependency graph functionality into Trac. Tickets set to block other tickets, or being blocked by other tickets, will be shown in a directed graph, clearly stating the tickets blocking other tickets. Depgraphs are accessible directly from within tickets with dependencies and can also be created by a macro from within a wiki page: Usage in
BatchModifyPlugin に restrict_owner=true を反映する - miauのブログ
Trac には BatchModifyPlugin というチケットを一括編集できるプラグインがあって、チケットのたな卸しなんかのときに便利なわけですが。restrict_owner=true（担当者の入力欄をプルダウンにするオプション）が反映されないようなので、軽くいじってみました。 変更点 ちょろい変更です。 --- web_ui.py.org 2009-09-12 19:00:26.000000000 +0900 +++ web_ui.py 2009-09-12 19:01:45.000000000 +0900 @@ -100,6 +100,8 @@ for field in TicketSystem(self.env).get_ticket_fields(): if field['name'] not in ('summary', 'reporter', 'description')
作業時間記録プラグインの状況 - wadahiroの日記
DQNにやられっぱなしですが、ちょっとずつプロトを作ってます。 表示するチケットのフィルタリング、グループ化を設定できるようにした。 フィルタリングは、特定ユーザの担当のチケットの表示に加えて、 クローズチケットも含む CCとなっているチケットも含む くらいでいいかなぁ。。。こういうフィルタリングしたい、という意見があれば欲しいところ。 グループ化はチケットフィールド(カスタムフィールドもOK)で好きなだけ設定できるようにした。下図は、Component-Typeでグループ化をして表示した例。 ganttcalendarpluginを真似て、マウスオーバさせるとチケットの詳細が簡易表示されるようにもしてみた。 ここまで作ってみて、ガントチャートも合わせて表示できそうな気がしてきた… チケットの依存関係がカスタムフィールドで設定されていれば、MSProjectライクにTicketをネストさせ
今までTrac関係で作ったものの関係をまとめる。 - いつまでもとりあえず
これらを解決するために，私が作ってきたものがどこにからんでくるかということを，次の図にしました．この図ならなんとかわかってもらえるのではないかと 1. InterTracCommitPatch コミットメッセージを，同じサーバ上の隣のプロジェクトにつけることを可能にします．これにより，今までは，要件定義，工程，実作業，障害などは，同じリポジトリを使う必要があため，どれだけ扱う項目（カスタムフィールド）が違っていたとしても，同じプロジェクトで扱うしか方法がありませんでした．これがあれば，リポジトリの縛りから解放され，プロジェクトを自由に分割することができます． 2. TracDepenecencyPlugin 同じサーバのTracプロジェクト間でチケットの親子関係と，依存関係を扱えるように拡張し，Tracのプロジェクトを分割することが容易になります．カスタムフィールドの入力のところのチェック
Trac(0.11.5) って重すぎやしませんか - 肉とビールとパンケーキ by @sotarok
てことで色々試してはみたんだけど，どうにもこうにも重すぎる気がします．誰か良い方法を知ってませんか？ ためしてみたこと mod_python -> mod_wsgi うーん，心無しか速くなった気も．．． でも劇的な改善，みたいなものはないですね．所詮は Trac 本体そのものが重いんでしょうか． 考えられるものとして，DBへアクセスする部分が非常に重い（特にTimeline系とか）ので，色々情報とってきてほげほげは重いのかもしれない．timelineに表示する日数減らすとか情報減らすとかすれば少しは改善するかも．一応SQLiteの中身も見てみたけどIndexは張ってあるくさいしなあ． あと，WSGIをデーモンプロセスモードで動かしてみるとかいうこともやってみました． こうすると，DBへのアクセスが頻発するページ以外はたしかに爆速に！！！ ところが，Tracつかってるとしばしばおこる，DBが
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Tracの情報をもとにExcelで作ったレポートをPDF化し，Tracのチケットに添付してしまうところまでを自動化したい． - いつまでもとりあえず
MS-Project複数プロジェクト対応版 - いつまでもとりあえず
worktimeplugin進まず... - wadahiroの日記