Mantis のバグかな？

Mantisで案件管理をしているが、検索のソート順で２項目を指定した場合にカスタム項目が含まれているとエラーになる。

「データベースの検索に失敗しました。データベースからエラーを受け取りました。 #1066: Not unique table/alias: 'mantis_custom_field_string_table' 」

バージョン:1.1.18 のバグなのか、最新版に入れ替えて確認したいところだが...
今は、とりあえずエラーがでないように検索を行って後で検証することにしよう。

Mantis 日付（年）の選択範囲を変更

Mantisで昨年の案件を追加しようとしたら、追加した日付のカスタム項目の年が 2011 ～ 2015 と表示され昨年(2010）が表示されないため選択できない。（日付はセレクトボックスで年・月・日が表示される）

昨年も同様の現象があったように思うが、昨年はセレクトボックス表示を解除して対応したのかもしれないが、今年は昨年から表示されるように改良することにした。

修正前は、2011年から2015年が表示される。
2010年を指定したいのだが表示されないので指定できない。

修正後は、2010年から2014年が表示されるよになり、2010年を指定することが可能になった。
めでたし、めでたし。(^^ゞ

修正するプログラムは、core フォルダの中の date_api.php です。（coreの中を修正するとバージョンアップの時に再度修正が必要かも）
下記に修正箇所を記載します。
date_api.php の中の print_year_range_option_list関数の先頭を修正します。
修正前 → $t_current = date( "Y" );
修正後 → $t_current = date( "Y" ) - 1;

  function print_year_range_option_list( $p_year = 0, $p_start = 0, $p_end = 0) {
    $t_current = date( "Y" ) - 1; /* 2011.01.08 */
    $t_forward_years = config_get( 'forward_year_count' ) ;

    $t_start_year = $p_start ;
    if ($t_start_year == 0) {
      $t_start_year = $t_current ;
    }
    if ( ( $p_year < $t_start_year ) && ( $p_year != 0 ) ) {
      $t_start_year = $p_year ;
    }

    $t_end_year = $p_end ;
    if ($t_end_year == 0) {
      $t_end_year = $t_current + $t_forward_years ;
    }
    if ($p_year > $t_end_year) {
      $t_end_year = $p_year + $t_forward_years ;
    }

    for ($i=$t_start_year; $i <= $t_end_year; $i++) {
      if ($i == $p_year) {
        PRINT " $i " ;
      } else {
        PRINT " $i " ;
      }
    }
  }

「Table 'xxxxxxxx' is marked as crashed and should be repaired」

　Mantis で検索を行おうとしたら、「Table 'xxxxxxxx' is marked as crashed and should be repaired」と表示されその下にSQL文が表示され検索画面を表示できなくなってしまった。^^;

なにやら repair しろと記載されているので、repair コマンドを実施。

repair table table_name;

無事に表示されました。(^o^)／

MySQLはあまりクラッシュすることはないらしいが、更新中にデーモン（mysqld）が停止してしまうとクラッシュすることもあるらしい。　特にMantisの更新中にデーモンが停止（またはLinuxサーバーを再起動）などなかったはずなのだが...
　ただ、相変わらず Linux のデスクトップは不調でブラウザやファイルブラウザを操作していると scim-bridge がクラッシュし、何回か続くとログオフされてしまうこともあるがこれとは関係ないな。

MySQLでテーブルに障害が発生したら、
　check table テーブル名;
でテーブルのエラーを調べ、
　repair table テーブル名;
でテーブルの修復を行うようだ。しかし、repair table コマンドは　MyISAM と ARCHIVE テーブルに対して機能しないらしい。　MySQL 5.1.9 から、REPAIR は CSV テーブルにも有効になりました。

　いつも Oracle ばかりで MySQL はあまり詳しくないのですが、Mantis を利用してプログラムの修正や案件の管理をしているという Mantis にかなりお世話になっている状態なので、今回を機会にきちんとバックアップをとり復旧方法も確認しないといけないことを実感した。　(ーー;)