RedmineのチケットNo.を1に戻す手軽な方法


Redmineをインストールしてあれこれと初期設定していると,テストチケットを発行することと思います。

デモ環境のような使い方を経て正式導入に移行する場合,このテストチケットは全削除してしまうと思いますが,ここで案外悩むのが「チケットNo.が最後に発行した情報のまま」ということです。どういうことかというと,デモ環境にてチケットNo.25まで発行していた場合,全削除したとしても次に発行すると26が割り当てられます。つまり,1~25までが欠番のように見えるわけで,その経緯を知らない人にとっては気持ち悪いことこの上ないわけです。

これを簡単に解決する方法があります。

  • 全てのプロジェクトを関連情報含めて削除する
  • Redmineを再起動する

コードを追っていないので推測ですが,Redmineは起動時にチケットの情報をスキャンし,最後のチケットのNo.を見つけたらそれを内部のカウンターに保持し,以後,新規発行時にそのカウンターの値を使っているようです。

なので,チケットが存在しない状態だと,0もしくは1がセットされることになります。こうして,新規発行するとチケットNo.は1となります。めでたしめでたし。

※全てのプロジェクトを完全削除する理由ですが,DBにチケットの情報が残ったままにならないようにするためです。通常のチケット削除操作は見えなくするだけなので,DBに情報は残ったままです。

Bitnami Redmine Stack のデータを手軽にバックアップ・リストアできるツール「RedArmory」


Bitnami Redmine Stack はWindows環境へのセットアップが簡単で重宝している方も多いと思います。ただし,データのバックアップ・リストアは少々面倒くさいと感じている方も多いのではないかと思います。

コンソールからコマンドを叩くのが次第に面倒になりバッチを組み始めるもWindows環境は何かとハマリポイントがあり,さらに面倒になって挫折してしまうといった次第です。実際,セットアップのお手軽さからBitnamiに手を出すも,保守観点の面倒くささから利用を挫折する方を何人も見かけました。もったいないことです。

そんな方々を救ってくれるのがTakuya Takeuchi氏によって昨年末に公開された「RedArmory」です。

■RedArmoryとは

RedArmoryとはBitnami Redmine Stack のデータのバックアップ&リストア機能を持つオープンソースのツールです。

■インストール方法

ツールはgithubに公開されており,ツールの説明もあります。

https://github.com/takuya-takeuchi/RedArmory

Download zip で持っていってビルドするのもいいのですが,おそらくBitnamiを使う方はこの手の作業に慣れていない方も多いと思いますので,リリースされているバイナリをダウンしましょう。次のページからバイナリがダウンロードするのがお手軽です。(記事執筆時,Version 1.0.0.10)が公開されていました。)

https://github.com/takuya-takeuchi/RedArmory/releases

■ツールの実行

zipを解凍すると「RedArmory.exe」というファイルがあるので実行しましょう。インストールも必要なく実行可能です。

RedArmory

掲載したスクリーンショットではBitnamiがないですよと警告が出ていますが,実際にはインストールしたものが認識されて表示されます。あとは左側のメニューからバックアップ&リストアするだけです。(そのうちスクリーンショットは差し替えます)

■今後の期待

さて,これだけでもとっても便利なのですが,今後アップデートされることがあるならば,以下の機能を期待したいところです。

  • スケジュール実行
  • バックアップ時にできるフォルダ名に「yyyy/mm/dd」を付加
  • バックアップファイルのリスト化とファイルの削除機能

おそらくこれが実装されたらBitnami Redmine Stack のバックアップツールとしては最強になるのではないかと思います。

誰もがほしいなぁと思っていたツールを作っていただいて,助かっている方は相当数に上るのではと思います。また筆者もその一人です。感謝ですね。

Redmine 3.2 でカスタムフィールドの型に「キー・バリュー・リスト」が追加されていた


先日のOPENSHIFTの件といい,少しRedmineを触りなおしています。

Redmineは3.0までは触っていたのですが少し間が空いてしまいました。故に最新版である3.2系とはそれなりにギャップがあり過去あれこれと対処をしていたりいまひとつと感じていたところが改善されていました。

改善の中で最もインパクトを与えたのは「キー・バリュー・リスト」の追加です。

カスタムフィールドの型にはこれまで「リスト」がありましたが,これは確かに便利なのですが,リストに設定した選択肢の名称を運用中に変更すると,すでに入力されていたデータは新しい名称には変更されず元の名称のままデータが残ります。ですので,便利だけれど頻繁にリストの選択肢内容をメンテナンスするようなプロジェクトでは使いどころが難しいものでもありました。

キー・バリュー・リストはこの問題を解決します。キー・バリュー・リストでは途中で選択肢の名称を変更した場合,すでに入力済みのデータも変更してくれます。

このため,3.2以降はよほどのことがないかぎりリストは使わず,キー・バリュー・リストを使うのが良いでしょう。

そのほか,3.2ではチケットのCSVからのインポートが標準機能として取り込まれたり,ワークフローで新しいチケットのステータスの初期値・選択肢が設定可能になったりしています。かなり便利になっていますので,以前のバージョンを使っている方も移行すると得が多いのではないかと思います。