iDempiere Kanban 踩坑三語實錄：主管才能改優先度，postEvent 救了全世界

Part 1: Priority Is the Boss’s Exclusive Toy

The requirement is straightforward: only the direct supervisor of the requestor (AD_User_ID) can edit the “Priority” field. The person in charge (SalesRep) and the requestor can see it just fine — they just can’t touch it. Whether something is urgent is not their call. It’s the boss’s call. Always.

Implementation: isSupervisorOf() in RequestKanbanVM.java

One SQL query. No recursive org-chart traversal. Just check if the current user is the direct supervisor of the requestor:

public boolean isSupervisorOf(int adUserId) {
    int myId = Env.getAD_User_ID(Env.getCtx());
    int supervisorId = DB.getSQLValue(null,
        "SELECT supervisor_id FROM ad_user WHERE ad_user_id = ?", adUserId);
    return supervisorId == myId;
}

Then in setupUpdateDialog() in RequestKanbanForm.java, wire up the permissions:

boolean canEdit      = vm.canEditRequest(request);   // SalesRep or Requestor
boolean isSupervisor = vm.isSupervisorOf(request.getAD_User_ID());
boolean canEditAny   = canEdit || isSupervisor;

// Priority — supervisor only
fUpdatePriority.setReadWrite(isSupervisor);

// Everything else — supervisor or anyone with edit rights
fUpdateSalesRep.setReadWrite(canEditAny);
fStartTime.setDisabled(!canEditAny);
fEndTime.setDisabled(!canEditAny);
fUpdateResult.setReadonly(!canEditAny);
btnSave.setDisabled(!canEditAny);

Key point: canEditRequest() and isSupervisorOf() are independent. If you happen to be both the supervisor and the SalesRep, canEditAny = true and isSupervisor = true — you can edit everything. Lucky you.

Part 2: Real-Time Cross-Browser Refresh — Three Failures, One Revelation

The Problem

User A saves a request. User B’s Kanban board keeps showing stale data. The OSGi EventHandler is wired up. So why isn’t it working?

Failure #1: this.getDesktop() returns null inside the handler

// WRONG: getDesktop() called from an OSGi EventAdmin thread may return null
@Override
public void handleEvent(org.osgi.service.event.Event event) {
    Desktop desktop = this.getDesktop();  // nobody's home
    if (desktop == null || !desktop.isAlive()) return;
    Executions.schedule(desktop, e -> vm.refreshCurrentView(), ...);
}

getDesktop() only has meaning on a ZK request thread. Calling it from an OSGi thread is like phoning someone who has already left the office. It just returns null and moves on.

Failure #2: Wrong event topic

We assumed iDempiere’s model event topic looked like this:

org/compiere/model/R_Request/*

It doesn’t exist. The correct topics are defined in IEventTopics:

PO_AFTER_NEW    = "adempiere/po/afterNew"
PO_AFTER_CHANGE = "adempiere/po/afterChange"
PO_AFTER_DELETE = "adempiere/po/afterDelete"

Broadcasting to a nonexistent topic is technically valid Java. It is completely useless.

Failure #3: sendEvent() is synchronous (the real trap)

ModelValidationEngine.fireModelChange()
  → EventManager.getInstance().sendEvent(event)   ← SYNCHRONOUS
    → subscriber.handleEvent() runs on Browser A's ZK request thread
      → Executions.schedule(myDesktop_B, ...)
        → Browser B's server push NOT correctly triggered

sendEvent() is synchronous per the OSGi EventAdmin spec. The handler runs on Browser A’s ZK thread. Calling Executions.schedule() for Browser B’s desktop from within Browser A’s active ZK execution does not correctly trigger Browser B’s server push. Like trying to call a friend while you’re already on a call with them — it just doesn’t connect.

The Fix: postEvent() — one word, hours of debugging

request.save()
  → vm.broadcastRefresh()
    → EventManager.getInstance().postEvent(...)   ← ASYNC, returns immediately
      → [OSGi EventAdmin thread]
        → subscriber.handleEvent()
          → Executions.schedule(myDesktop_B, ...)  ← called from non-ZK thread ✅
            → Browser B server push wake-up ✅
              → vm.refreshCurrentView() ✅

Full Implementation

Step 1: Custom topic constant

public static final String TOPIC_KANBAN_REFRESH = "kanbanform/request/refresh";

Step 2: broadcastRefresh() — fire after every save

public void broadcastRefresh() {
    EventManager.getInstance().postEvent(
        new org.osgi.service.event.Event(TOPIC_KANBAN_REFRESH, new java.util.HashMap<>()));
}

Called at all three save points:

// Drag-drop status change
if (!req.save()) { ... return; }
broadcastRefresh();
refreshKanbanData();
BindUtils.postNotifyChange(this, "*");

// New request dialog
if (!req.save()) { ... return; }
broadcastRefresh();
refreshKanbanData();
BindUtils.postNotifyChange(this, "*");

// Update dialog save
if (anyChange) {
    request.save();
    vm.broadcastRefresh();
}
dialog.detach();
vm.refreshCurrentView();

Step 3: Capture desktop at init + enable server push

myDesktop = Executions.getCurrent().getDesktop();
if (!myDesktop.isServerPushEnabled()) myDesktop.enableServerPush(true);

@Override
public void onPageAttached(Page newpage, Page oldpage) {
    super.onPageAttached(newpage, oldpage);
    if (newpage != null && !newpage.getDesktop().isServerPushEnabled())
        newpage.getDesktop().enableServerPush(true);
}

Why capture at init? Executions.getCurrent() is only available on a ZK request thread. Store it then, and it’s always available — never null — inside the OSGi handler. Write down the address before you leave the house, not after you’re already lost.

Step 4: Register the subscriber

private void registerOsgiEventHandler() {
    eventSubscriber = osgiEvent -> {
        if (myDesktop == null || !myDesktop.isAlive()) return;
        try {
            Executions.schedule(myDesktop,
                e -> vm.refreshCurrentView(),
                new Event("onServerPushRefresh"));
        } catch (Exception ex) {
            log.log(Level.WARNING, "Kanban refresh schedule failed", ex);
        }
    };
    EventManager.getInstance().register(
        RequestKanbanVM.TOPIC_KANBAN_REFRESH, eventSubscriber);
}

Step 5: Unregister on detach (skip this and your server cries)

@Override
public void onPageDetached(Page page) {
    if (eventSubscriber != null) {
        EventManager.getInstance().unregister(eventSubscriber);
        eventSubscriber = null;
    }
    super.onPageDetached(page);
}

Without this, the subscriber keeps running after the tab is closed — the software equivalent of an ex who still has your Netflix password. Consuming resources, serving no purpose, slowly draining memory until someone notices the server is sluggish.

Step 6: refreshCurrentView() — handles all three views

public void refreshCurrentView() {
    if (VIEW_GANTT.equals(currentView)) {
        refreshGanttHtml();
        refreshProjectPanel();
    } else {
        refreshKanbanData();
        BindUtils.postNotifyChange(this, "*");
    }
}

The Three Rules