Project

General

Profile

Actions

QA #1400

open

チケット編集時のバリデーションエラー発生時の振る舞いについて

Added by m t 2 months ago. Updated about 2 months ago.

Status:
新規
Priority:
通常
Assignee:
-
Category:
-
Target version:
-
Start date:
06/01/2022
Due date:
% Done:

0%

Estimated time:

Description

■現象/要望

view customizeを使用し、チケット編集時の担当者リストを表示制御していますが、
必須項目等のバリデーションチェックエラーとなった場合、
上部にエラーメッセージが表示されますが、
その際、担当者リストがデフォルト(view customize適用前)になります。

入力途中の内容を保持するためか、ページのリロードが行われず、
view customizeのコードは実行されず再表示が行われるためかと思われます。

バリデーションエラー時もview customizeのコードが適用された担当者リストを表示したいと考えております。

このような事象に対して、対処等された方がおられましたら、
対処方法等をご教示いただきたくお願いいたします。

redmineバージョンは、4.2です。
よろしくお願いいたします。

■解決策

■対応状況

■補足

Actions #1

Updated by m t 2 months ago

  • Description updated (diff)
Actions #2

Updated by m t 2 months ago

  • Description updated (diff)
Actions #3

Updated by 奈良 裕記 2 months ago

解決策は不明ですが、手元の環境で再現する事を確認しました。

>入力途中の内容を保持するためか、ページのリロードが行われず、
>view customizeのコードは実行されず再表示が行われるためかと思われます。

そのように思われます。
models/issue.rb の、validate_custom_field_values から辿って、
lib/redmine/field_format.rb にて、CF定義で指定されたvalidationのチェックとエラー表示が行われています。

redmine/field_format.rb: errs << ::I18n.t('activerecord.errors.messages.too_long', :count => custom_field.max_length)

Actions #4

Updated by m t 2 months ago

ありがとうございます。
やはりコア対応しかなさそうですかね。

もう少しご意見を伺ってみたいと思います。

Actions #5

Updated by 奈良 裕記 2 months ago

@m t

作者のonozatyさんに問い合わせましたが、リロードされるはずで再現しないとのことでした。
https://twitter.com/onozaty/status/1533253999939690497

何等かの発生条件があるのだろうと思います。
再現条件を確認したいので、詳細教えて下さい。
公開できる範囲で構いません。
使用プラグインもお願いします。

Actions #6

Updated by m t 2 months ago

ありがとうございます。

そういうことであればコードが怪しいかな?と思いましたが、
コードにalertを入れてみると、バリデーションエラー時には表示されないので、
やはり実行自体されていないのかな?と思いました。
初回表示では正常なので、コード自体は動作しているようです。

担当者リストを生成/セットするスクリプト(View Customize)と
プラグイン情報をお知らせします。
コードについては、case分の設定値等は削除/マスクしております。

【View Customize①】の実行パスは、/issues/new$ですが、
同様のコードに起票者(owner)情報を追加したもの【View Customize②】を、
/issueパスで登録しています。

お手数をお掛け致しますがよろしくお願い致します。

<スクリプト要因の可能性あり>との見通しがあると判明したため、
コード類の表記は削除させていただきました。

※原因は、次コメントに記載

Actions #7

Updated by m t about 2 months ago

リロードされるはず、とのご指摘を前提に確認を進めていたところ、
スクリプト要因と思われる下記の事象が想定されました。

<想定される原因>
・スクリプトは、”新規用”と”新規以外用”で実行パスを分けていた。
・分けた理由は、owner情報やcurrent_assign情報の設定が必要であるため。
・新規の場合でも、バリデーションエラーの際の実行パスは、issues/となる。
・このため、新規の場合でバリデーションエラーとなる場合、”新規以外用”が実行される。
・この際、owner情報やcurrent_assign情報が取得できずエラーとなる。

上記想定のもの検証しております。
結果、追ってご報告いたします。

お騒が致しました。
ご協力ありがとうございました。

Actions #8

Updated by m t about 2 months ago

新規の場合でも、バリデーションエラーの際の実行パスは、issues/となることから、
新規の場合と既存編集の場合で分けていたスクリプトを一つにすることで解決したいと考えました。

スクリプト内で新規かどうかを判定し、
既存の場合はissue情報を取得し起票者を設定したいと思っていますが、

”スクリプト内で新規かどうかを判定”で苦慮しております。
/newのパス判定では、バリデーションエラー時に/newパスで実行されないため、

別の要素で判定しなければならないと思っていますが、
contextでは/newの場合にエラーになるなど、思うように実現できません。

すみませんが、お知恵をお貸し頂ければ思います。
よろしくお願いします。

Actions

Also available in: Atom PDF