ken_nogi/Pleasanter/新・稟議申請システム/modify/2026-08-29T1620_after_set無限ループ修正/summary.md

修正サマリー：SiteId 319015（新・稟議申請書）

• 対象: Script Id:1（1.新・稟議申請書.js）
• 反映方法: build-desired-config.js → apply-desired-config-full.js --execute（updatesite全体更新）
• 反映結果: HTTP 200 "新・稟議申請書"を更新しました。（1回目のみ反映失敗、2回目で成功。詳細は末尾参照）

症状

/pleasanter/items/319015/new?FromSiteId=160926&LinkId=507815&FromTabIndex=0&NotReturnParentRecord=false （160926「稟議コード管理」からのLinkポップアップ経由の新規作成画面）で、コンソールに after Set (保存後の画面更新) → initialize が無限に繰り返される。

原因

1. 1段目の原因（2026-08-28修正時に混入）: $p.events.after_set ハンドラが init() を呼び、init() 内の new アクション分岐で $p.set($('#Results_Class003'), ...) 等を実行していた。これが直接の原因ではなく、
2. 真因: shiharaiTable()（支払いテーブル/jspreadsheet）の初期化時、minSpareRows:1 等の設定で ライブラリ内部から onchange コールバックが自動発火し、その中の $p.set($('#Results_NumM'), ...) / $p.set($('#Results_DescriptionX'), ...) が実行される。Pleasanterの $p.set() は連動更新(Set)を 伴い、完了時に after_set イベントを再発火させる。 after_set → init()/initAfterSet() → shiharaiTable()再生成 → onchange自動発火 → $p.set() → after_set再発火 という無限ループになっていた。

変更点

1. after_set ハンドラの分離（1段目対応）

after_set 発火時は init() ではなく専用の initAfterSet() を呼ぶよう変更。 initAfterSet() は init() から new専用の $p.set() 系処理（社員番号自動補完・ClassD初期化・ 稟議コード発行チェック・通知宛先補完・事故報告書テンプレート）を除いたもの （readonlyColumn / changeZeikomi / ClassR表示切替 / editableFlag / shiharaiTable のみ実行）。

2. shiharaiTable() の初期化中onchangeガード（真因対応）

function shiharaiTable() {
    ...
    let shiharaiTableInitializing = true;

    myTable1a = jspreadsheet(document.getElementById('myTable1'), {
        ...
        onchange: function (el, cell, x, y, value, oldValue) {
            if (shiharaiTableInitializing) return;   // ★追加：初期化中の自動発火を無視
            ...(既存処理、$p.set呼び出し含む)
        }
    });

    shiharaiTableInitializing = false;   // ★追加：初期化完了後のみonchange処理を有効化
}

反映時のトラブルと対処（記録）

1回目の apply-desired-config-full.js --execute はHTTP 200を返したが、実際は未反映だった。 原因は build-desired-config.js の実行を省略し、プロジェクト直下の古い desired_config.json （8/28時点のもの、修正前の内容）をそのまま送信していたため。 apply-desired-config-full.js は --site オプションを解釈せず、desired_config.json 内の SiteId を使う仕様のため、事前に build-desired-config.js site-319015_新・稟議申請書 を実行して desired_config.json を最新化してから --execute する必要がある。 この際、未送信のままライブファイルを get-site-config.js で再取得してしまい、ローカル編集が 一度巻き戻る事故も発生（修正は再適用済み）。 2回目の実行では build-desired-config.js を先に実行し、desired_config.json に修正内容が 含まれることを確認してから --execute → 再取得で正しく反映されたことを確認済み。

追加調査（2026-08-29 継続）

上記対応後もブラウザ実機で無限ループ再現。切り分けのため after_set ハンドラの中身を 一時的にログのみ（init()/initAfterSet() 呼び出しなし）に変更して反映したところ、 それでも after Set (保存後の画面更新) ログだけが無限連発し続けることを確認。 → 原因はカスタムJS(Script Id:1)ではなく、Pleasanter標準機能側と判明。

319015 の Column「ClassL」（稟議コードリンク、SiteId:160926参照）の設定に以下を確認：

"ColumnsReturnedWhenAutomaticPostback": "ClassA, ClassB, ClassC, ClassD",
"Lookups": [
  { "From": "ClassC", "To": "ClassA" },
  { "From": "ClassA", "To": "ClassB" },
  { "From": "ClassB", "To": "ClassC" },
  { "From": "ClassF", "To": "ClassG" }
]

推定原因: ColumnsReturnedWhenAutomaticPostback（この列群が変わったら自動サーバー連動＝ AutomaticPostbackする設定）に、Lookupで自動反映される側の列（ClassA/B/C＝Toの結果）自身が 含まれているため、「ClassL変更→Postback→Lookupで ClassA/B/C 自動セット→その変更がまた Postbackをトリガー」という無限連鎖になっていると推測。ただし未検証（下記の理由で保留）。

対応案として ColumnsReturnedWhenAutomaticPostback を "ClassD" のみに絞る変更を提案したが、 本番テーブルのため試行錯誤せず一旦保留とし、全てのカスタムJS変更（Script Id:1）を 2026-08-28時点の内容に完全復元済み（build-desired-config.js → apply-desired-config-full.js --execute → get-site-config.js で復元後の内容がサーバー側に反映されたことを確認）。

保留・見送り事項

• ClassL列の ColumnsReturnedWhenAutomaticPostback 設定変更は未実施（本番のため要相談）。
• 現状、無限ループの症状（160926からのLink経由new画面）は未解消のまま。
• Script Id:1 は無限ループ対応前（2026-08-28時点）の内容に復元済み。