OpenPNE 3

本件には直接関係しませんが、気になったのでコメントしておきます。

MemberProfileForm.class.php の 56〜74 行目ですが、現在次のように書かれています。

      if (!$memberProfile)
      {
        if (null === $value['value'])
        {
          continue;
        }
        $memberProfile = new MemberProfile();
        $memberProfile->setMemberId($memberId);
        $memberProfile->setProfileId($profile->getId());
      }
      elseif (null === $value['value'])
      {
        if ($profile->isMultipleSelect())
        {
          $memberProfile->clearChildren();
        }
        $memberProfile->delete();
        continue;
      }

この部分は次のように記述した方が読みやすいかもしれません。

      if (null === $value['value'])
      {
        if ($memberProfile)
        {
          if ($profile->isMultipleSelect())
          {
            $memberProfile->clearChildren();
          }
          $memberProfile->delete();
        }
        continue;
      }
      if (!$memberProfile)
      {
        $memberProfile = new MemberProfile();
        $memberProfile->setMemberId($memberId);
        $memberProfile->setProfileId($profile->getId());
      }

0を含む制限値の範囲指定ができるように修正されていますが、 #837 で対応したような、仮に (min, max) = (8, 4) のような大小関係が不正な場合に制限をしないとった対応がされていません。

また、2系のバリデータは (0, 0) が (制限なし) を意味していましたが、3系のバリデータは範囲制限を行ないます。そこで、(0, 0) を例外的に制限なしと見なすような仕様にするかを検討する必要があります。この問題の抜本的な解決方法はコンバータを改良することです（2系からのコンバート時に(0, 0)のものを(NULL, NULL)として保存するようにする）。

(0, 0) 問題について #837 ではこの範囲制限は文字列長を意味し、空文字を入力した場合は「0文字長のテキストを入力した」のではなく「入力を省略した」と見なされる仕様を理由に、(0, 0) を (NULL, NULL) と見なすような例外処理を加えていますが、数値範囲の場合は (0, 0) は即ち整数 0 のみを受け付ける制約として意味があるので (NULL, NULL) と見なしてよいか検討する必要があります。

上記3段落の内容をまとめると、

• (1) (min, max) = (8, 4) の範囲指定がされたままコンバートされると、不正な制約のせいで入力できなくなるので、(NULL, NULL) と見なすように修正しよう
• (2) 範囲指定がされていないままコンバートされると、(0, 0)という制約が付いてしまうので、コンバータの仕様を改善しよう
• (3) コンバータの仕様を直さないのであれば、コンバート後の (0, 0) が (NULL, NULL) を意味するようなバリデータの仕様を変更してよいか検討しよう（バリデータの仕様を変更する場合、管理画面から(min, max)を指定する際に(0, 0)が指定できるが、それが範囲指定なしを意味することになるので管理画面にも注意書きが必要になる）

ということになります。

to takai

• (1) (min, max) = (8, 4) の範囲指定がされたままコンバートされると、不正な制約のせいで入力できなくなるので、(NULL, NULL) と見なすように修正しよう
• (2) 範囲指定がされていないままコンバートされると、(0, 0)という制約が付いてしまうので、コンバータの仕様を改善しよう
• (3) コンバータの仕様を直さないのであれば、コンバート後の (0, 0) が (NULL, NULL) を意味するようなバリデータの仕様を変更してよいか検討しよう（バリデータの仕様を変更する場合、管理画面から(min, max)を指定する際に(0, 0)が指定できるが、それが範囲指定なしを意味することになるので管理画面にも注意書きが必要になる）

• (1)の件は修正します。

コンバーターの仕様を見直す方向に持って行こうと考えていますが、本件とはまたトピックが異なるため別チケットとします。

http://redmine.openpne.jp/issues/1478

Kousuke Ebihara は書きました:

問題ありません。

このチケットの確認中に now などの文字列が実際の日付に変換された上で DB に保存されてしまっているというバグを発見しました。これは実際には文字列として保存しておき、その文字列をバリデーションのために都度日付に直すのが正しい挙動です。このバグは #930 の 4e1f2665 の変更により混入したものと思われます。

このチケットでは日付の比較にも関わる変更がなされているので微妙なところですが、別のバグチケットを切って対処することにしましょう。

この件についてのチケットを作成しました。 http://redmine.openpne.jp/issues/1595