去年我做了一個 iDempiere Request 看板——tw.idempiere.requestkanban。它在 iDempiere 11 上面運作得很好。Kanban、Gantt、List 三種視圖，拖拉卡片，即時更新，主管也滿意，需求也關閉了。
我以為故事就這樣結束了。
然後 iDempiere 12 出來了。我升版了。看板還在，功能還在，介面也正常。我巡視了一圈，一切看起來都沒有問題。
但有件事不對。
幕一：犯罪現場不在現場
問題不在看板本身。看板開起來正常，Kanban 拖得動，Gantt 畫得出來，List 也列得整齊。
問題是——WebUI Host Plugin，在某些情況下，靜靜地失靈了。
不是崩潰。不是 Exception。不是 Stack Trace 噴一頁讓你一眼看出凶手。是那種「它應該在的東西不在了」、「這個功能昨天還好好的」的幽靈症狀。你看著日誌，日誌告訴你一切正常。你看著畫面，畫面告訴你有些東西不見了。這兩件事同時為真。
這種 Bug 是最可怕的一種——它不報錯，它只是讓你懷疑自己的記憶力。
幕二：排查，排查，再排查
我開始做最古老的偵錯儀式：逐一關掉 Plugin，看看哪個是凶手。
關掉這個，重啟，看看。沒事。
關掉那個，重啟，看看。沒事。
然後手指停在了 Dashboard Fragment 上。
停掉它。
WebUI Host Plugin：正常了。
就是你。
tw.idempiere.requestkanban 是以 Dashboard Fragment 的方式實作的。在 iDempiere 11，Fragment 住在 Dashboard 裡，乖乖不打擾任何人。但 iDempiere 12 的 OSGi 環境對 Fragment 的載入時序更敏感，我的 Fragment 在初始化過程中，踩到了 WebUI Host Plugin 的某條隱形地雷線——不是爆炸，是那種把線輕輕壓扁、讓電路接觸不良的踩法。
Fragment 沒有惡意。但它確實闖禍了。
幕三：搬家決定——好鄰居不惹事
修法一：留在 Dashboard Fragment，試著和 WebUI Host 和平共處，找到那條隱形地雷線，小心繞過。
修法二：放棄 Dashboard Fragment，改用 Custom Form，自立門戶，從此與任何宿主環境解耦。
我想了大概三秒鐘，選了修法二。
理由很簡單：好的 Plugin 應該獨立運作，不影響別人，也不被別人影響。 Dashboard Fragment 本質上是寄生在宿主環境裡的，你的初始化流程與宿主的初始化流程交纏在一起，這種結構天生就有干擾風險。Custom Form 是獨立的視窗，自己管理自己的生命週期，和鄰居完全沒有瓜葛。
搬家雖然費工，但好鄰居的代價，值得付出。
幕四：MVVM Custom Form 的新居
新版叫 tw.idempiere.requestkanbanform，版本號 2.0.0，代表這是一次真正的重建，不是小修。
架構的改變：
- 從 Eclipse PDE 改為 Maven Tycho 建構——現代一點，CI/CD 比較好整合，不用再跟 Eclipse 的視覺化設定介面搏鬥。
- 從 Dashboard Fragment 改為標準的 iDempiere Custom Form，以純 POJO 的 ZK MVVM ViewModel 實作。
- 不再依附 Dashboard 宿主，不再有 Fragment 生命週期的隱患，不再讓鄰居的 Plugin 無辜受害。
功能沒有退步：
- Kanban 視圖：拖拉卡片，依狀態分欄，顏色對應優先級，截止日提示還在。
- Gantt 視圖：時間軸自動調整粒度（日/週/月），依負責人分組，主管看了還是會點頭。
- List 視圖：傳統分頁表格，給不需要酷炫的人。
- OSGi EventAdmin 即時更新：一個人改了，所有人的畫面都跟著動。
- 範圍篩選：個人 / 部屬 / 團隊 / 全部，各取所需。
- 拖拉卡片的權限控制：只有 SalesRep 或 Requester 本人才能移動自己的卡片，防止有人手賤。
- 雙語介面：繁體中文 + English，開箱即用。
- 零新增資料表、零新增欄位：不動 schema，升版不踩地雷，這個原則繼承下來了。
一樣的功能，乾淨的架構，安分的 Plugin 公民。
幕五：給升版者的行動建議
如果你在 iDempiere 11：舊版 Dashboard 看板繼續用沒問題。但如果你打算升版，或者喜歡乾淨的架構，現在換新版也完全合理。
如果你在 iDempiere 12：請直接用新版 Custom Form 版本。舊版的 Dashboard Fragment 對 WebUI Host Plugin 不友善，不是它的本意，是 Fragment 在新版 OSGi 環境裡的先天體質問題。
安裝方式：Maven 編譯，OSGi bundle 部署，然後在 iDempiere 設定 Custom Form 指向此 Plugin。比 Dashboard 的設定方式更直覺，找得到、設得了、跑得起來。
結：雷公曰
Fragment 本無罪，時序有別，iDempiere 12 之 OSGi 環境更為嚴苛，昔日和平共處之 Fragment，今日竟成鄰居之患。雷公知過能改，棄 Dashboard 而投 Custom Form，以 MVVM 重新做人，從此獨居一隅，自管門戶，不擾他人，亦不受他人所擾。搬家雖費工，然好鄰居之道，在乎不惹事，而非假裝沒事。此次重建，既為相容，亦為自省。
如果新版幫你解決了升版後的相容性問題，歡迎到 GitHub 給顆星——讓雷公知道搬家是對的。
⭐ github.com/ray-idempiere/tw.idempiere.requestkanbanform
English
Fragment Trouble: iDempiere 12 Compatibility Crisis and the MVVM Custom Form Rebuild
Last year I built an iDempiere Request Kanban plugin — tw.idempiere.requestkanban. It ran fine on iDempiere 11. Three view modes: Kanban, Gantt, List. Drag-and-drop cards, real-time updates, management was satisfied, requirements were closed. I thought the story was over.
Then iDempiere 12 came out. I upgraded. The Kanban still opened. The features still worked. Everything looked fine.
But something was wrong.
Act 1: The Crime Scene Was Not at the Crime Scene
The problem wasn’t in the Kanban plugin itself. Cards dragged fine, Gantt rendered correctly, List displayed perfectly. The problem was that the WebUI Host Plugin, in certain situations, quietly stopped working. Not a crash. Not an exception. Not a stack trace pointing at the culprit. Just a ghost symptom: things that should be there weren’t. Functionality that worked yesterday didn’t work today. The logs said everything was fine. The screen disagreed. Both were simultaneously true.
This is the most dangerous kind of bug — it doesn’t throw errors. It just makes you question your own memory.
Act 2: The Usual Suspects
I performed the oldest debugging ritual: disable plugins one by one and see what changes. Disable this one, restart, check. Nothing. Disable that one, restart, check. Nothing. Then my finger stopped on the Dashboard Fragment.
Disable it.
WebUI Host Plugin: normal again.
It was you.
The original plugin was implemented as a Dashboard Fragment. In iDempiere 11 this was fine — the Fragment lived quietly inside the Dashboard and bothered no one. But iDempiere 12’s OSGi environment is more sensitive about Fragment initialization timing. My Fragment, during its initialization sequence, was silently stepping on something in the WebUI Host Plugin’s initialization path. Not an explosion — more like pressing down on a wire until the circuit lost contact.
The Fragment had no malicious intent. It just caused trouble anyway.
Act 3: The Relocation Decision
Option A: Stay as a Dashboard Fragment and carefully navigate around the invisible landmine field.
Option B: Abandon the Dashboard Fragment approach, switch to a Custom Form, and become an independent tenant.
I thought about it for roughly three seconds and chose Option B. The reasoning: a well-behaved Plugin should run independently without affecting others or being affected by them. A Dashboard Fragment is inherently parasitic on its host environment — your initialization lifecycle is entangled with the host’s lifecycle, and that entanglement carries interference risk by design. A Custom Form is an independent window that manages its own lifecycle, completely decoupled from its neighbors.
Moving is work. Being a good neighbor is worth it.
Act 4: The New MVVM Custom Form Home
The new version is called tw.idempiere.requestkanbanform, version 2.0.0 — because this was a genuine rebuild, not a patch.
Architectural changes:
- Build system: Eclipse PDE → Maven Tycho. More modern, easier CI/CD integration.
- Plugin type: Dashboard Fragment → standard iDempiere Custom Form, implemented as a pure POJO ZK MVVM ViewModel.
- No longer attached to any host environment. No Fragment lifecycle hazards. No collateral damage to neighboring plugins.
Functionality: unchanged. All three view modes retained — Kanban with draggable cards and priority colors, Gantt with auto-adjusting timeline granularity, List for people who don’t need the excitement. OSGi EventAdmin real-time updates still work. Permission-gated drag-and-drop still works. Scope filtering (personal / subordinates / team / all) still works. Bilingual UI (Traditional Chinese + English) still works. Zero new database tables or columns — this principle was too good to abandon.
Same features. Cleaner architecture. A Plugin that behaves itself.
Act 5: Migration Guide
If you’re on iDempiere 11: The old Dashboard version still works. But if you’re planning to upgrade, or you just prefer clean architecture, switching to the new Form version is completely reasonable now.
If you’re on iDempiere 12: Use the new Custom Form version directly. The old Dashboard Fragment is not friendly to WebUI Host Plugin in the newer OSGi environment — not intentionally, just constitutionally.
Installation: Maven build, OSGi bundle deployment, configure a Custom Form in iDempiere pointing to this plugin. More straightforward than the Dashboard setup — you can find it, configure it, and run it.
雷公曰
The Fragment was innocent. The problem was timing — iDempiere 12’s OSGi environment demands more discipline than its predecessor. A Fragment that coexisted peacefully on version 11 became a nuisance on version 12. Upon discovering this, Ray — that’s me — made the correct choice: abandon the Dashboard Fragment, rebuild as a Custom Form, and become a responsible independent tenant who minds his own business and lets his neighbors mind theirs. Relocation is work. Being a good neighbor is not optional. This rebuild was for compatibility, and also for character.
If the new version fixed your upgrade compatibility issues, a GitHub star goes a long way.
⭐ github.com/ray-idempiere/tw.idempiere.requestkanbanform
日本語
Fragmentの災難：iDempiere 12 互換性危機と MVVM Custom Form による再構築
昨年、iDempiere Request カンバンプラグイン tw.idempiere.requestkanban を作りました。iDempiere 11 では問題なく動作していました。カンバン、ガント、リストの 3 つのビュー、カードのドラッグ＆ドロップ、リアルタイム更新。上司も満足し、要件もクローズされました。話はそこで終わったと思っていました。
それから iDempiere 12 がリリースされました。アップグレードしました。カンバンは起動し、機能も正常、画面も問題なし。一通り確認して、大丈夫だと思っていました。
でも、何かがおかしかった。
第一幕：犯行現場は現場にない
問題はカンバン Plugin 自体ではありませんでした。カードはドラッグでき、ガントも描画され、リストも正しく表示されていました。問題は、WebUI Host Plugin が特定の条件下でひっそりと機能しなくなることでした。クラッシュではない。例外でもない。スタックトレースが犯人を指してくれるわけでもない。ただ、「あるべきものがない」という幽霊症状でした。
こういうバグが最も怖い——エラーを吐かず、ただ記憶力を疑わせる。
第二幕：容疑者を絞る
古典的なデバッグ儀式を実行しました。プラグインを一つずつ無効化して確認する。あれを無効化、再起動、確認。異常なし。これを無効化、再起動、確認。異常なし。そして指が Dashboard Fragment の上で止まりました。
無効化する。
WebUI Host Plugin：正常になった。
お前か。
元のプラグインは Dashboard Fragment として実装されていました。iDempiere 11 では Fragment はおとなしく Dashboard の中に住んでいて、誰にも迷惑をかけませんでした。しかし iDempiere 12 の OSGi 環境は Fragment の初期化タイミングに対してより敏感で、私の Fragment が初期化の過程で WebUI Host Plugin の初期化パスに干渉していました。悪意はない。でも、迷惑はかけていた。
第三幕：引越しの決断
選択肢 A：Dashboard Fragment のままで、地雷を慎重に避け続ける。
選択肢 B：Dashboard Fragment を捨てて Custom Form に移行し、完全に独立する。
3 秒考えて、選択肢 B にしました。理由はシンプル：良い Plugin は他に影響を与えず、他から影響を受けない。Dashboard Fragment はホスト環境に寄生する構造で、初期化ライフサイクルが絡み合い、干渉リスクが生まれる。Custom Form は独立したウィンドウで、自分のライフサイクルを自分で管理し、隣人とは完全に切り離されている。
引越しは手間がかかる。でも良い隣人でいることは、その価値がある。
第四幕：MVVM Custom Form の新居
新バージョンは tw.idempiere.requestkanbanform、バージョン 2.0.0。パッチではなく、真の再構築です。
ビルドシステムを Eclipse PDE から Maven Tycho に変更。Plugin タイプを Dashboard Fragment から標準の iDempiere Custom Form（純粋な POJO ZK MVVM ViewModel）に変更。ホスト環境への依存をなくし、Fragment のライフサイクルリスクをなくし、隣人の Plugin への影響をなくしました。
機能は退化なし。カンバン、ガント、リストの 3 ビューはすべて健在。OSGi EventAdmin リアルタイム更新、権限付きドラッグ＆ドロップ、スコープフィルタリング、バイリンガル UI（繁体字中国語 + English）、データベーススキーマ変更ゼロ——すべて引き継ぎました。
第五幕：移行ガイド
iDempiere 11 をお使いの方：旧バージョンの Dashboard 版は引き続き使えます。アップグレード予定がある場合、または綺麗なアーキテクチャを好む場合は、今すぐ新バージョンに切り替えることも合理的です。
iDempiere 12 をお使いの方：新バージョンの Custom Form 版を直接使ってください。旧バージョンの Dashboard Fragment は新しい OSGi 環境での WebUI Host Plugin との相性が良くありません。
雷公曰
Fragment に罪はない。問題はタイミングだ。iDempiere 12 の OSGi 環境はより厳格で、バージョン 11 で平和に共存していた Fragment が、バージョン 12 では迷惑な隣人になってしまった。この事実を認め、Dashboard Fragment を捨て、Custom Form として再生し、自立した Plugin 市民になることを選んだ。引越しは手間だ。でも良い隣人でいることは選択ではない。今回の再構築は互換性のためであり、同時に自省でもある。
新バージョンがアップグレード後の互換性問題を解決した場合は、GitHub スターで応援してください。
⭐ github.com/ray-idempiere/tw.idempiere.requestkanbanform
