# 修正サマリー：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ガード（真因対応）

```js
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参照）の設定に以下を確認：

```json
"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時点）の内容に復元済み。