你的 EndTime 被偷了：iDempiere Model Sandwich Pattern 完全指南 🥪

Prologue: Your Sandwich Filling Has Gone Missing

It’s an ordinary afternoon. You open iDempiere, cheerfully set the EndTime on a request ticket via your Kanban board, hit Save — and the field vanishes.

Not a UI glitch. Not a fat-finger moment. The database genuinely says NULL.

You try again. Gone. You try once more. Still gone. You stare at the screen for three seconds and quietly begin to question your career choices.

Welcome to this post’s central mystery: someone in the kitchen is eating your sandwich filling every single time, and they keep getting away with it.

Chapter 1: Identifying the Filling Thief

The suspect list starts long. MRequest.beforeSave()? Checked. Innocent. Your plugin logic? Reviewed. Clean. The Kanban form? Not guilty.

The real culprit is hiding deep in core code, wearing the most harmless name imaginable:

RequestEventHandler, from org.adempiere.base.

It quietly registers itself for four R_Request save events:

registerTableEvent(IEventTopics.PO_BEFORE_NEW,    I_R_Request.Table_Name);
registerTableEvent(IEventTopics.PO_BEFORE_CHANGE, I_R_Request.Table_Name);
registerTableEvent(IEventTopics.PO_AFTER_NEW,     I_R_Request.Table_Name);
registerTableEvent(IEventTopics.PO_AFTER_CHANGE,  I_R_Request.Table_Name);

Every time PO_BEFORE_CHANGE fires, it runs beforeSaveRequest() — auditing changes, sending notifications — and then, without a second thought, cleans out your filling:

// RequestEventHandler.beforeSaveRequest() — the scene of the crime
r.setEndTime(null);             // ← here, every single time
r.setR_StandardResponse_ID(0);
r.setR_MailText_ID(0);
r.setResult(null);

This runs on every R_Request save — regardless of which field you actually changed. Updated the summary? EndTime gone. Changed the status? EndTime gone. Saved without changing anything? EndTime still gone.

And we can’t touch core. Plugin rules. Iron law.

Chapter 2: The Kitchen’s Standard Operating Procedure

To outsmart a kitchen colleague who refuses to play fair, you first need to understand the kitchen’s exact sequence of operations.

When PO.save() is called, iDempiere executes in this order:

PO.save()
  │
  ├─ 1. PO.beforeSave()                    ← your override runs HERE (earliest)
  │       └─ super.beforeSave()
  │
  ├─ 2. ModelValidationEngine
  │       └─ IModelValidator (TIMING_BEFORE_CHANGE)
  │
  ├─ 3. EventManager.sendEvent(PO_BEFORE_CHANGE)
  │       └─ RequestEventHandler.beforeSaveRequest()
  │               └─ r.setEndTime(null)    ← filling stolen HERE
  │
  ├─ 4. SQL INSERT / UPDATE                ← EndTime = NULL written to DB
  │
  ├─ 5. PO.afterSave()                     ← your override runs HERE (last)
  │       └─ super.afterSave()
  │
  ├─ 6. ModelValidationEngine
  │       └─ IModelValidator (TIMING_AFTER_CHANGE)
  │
  └─ 7. EventManager.sendEvent(PO_AFTER_CHANGE)
          └─ RequestEventHandler.afterSaveRequest()

The key insight:

• PO.beforeSave() is called directly by PO.save() as a protected method — it runs before any OSGi event is dispatched.
• RequestEventHandler is an OSGi EventHandler; iDempiere only fires PO_BEFORE_CHANGE after beforeSave() has already returned.
• afterSave() runs after the SQL write — it’s the last line of defense.

Translation: you have a window to hide the filling before the thief strikes, and another window to stuff it back in after they’ve left.

Chapter 3: The Sandwich Pincer Maneuver

The solution’s name already explains everything:

Step 1 — beforeSave (ours)
         └─ stash EndTime into PO Attribute   ← before RequestEventHandler strikes

Step 2 — EventManager fires PO_BEFORE_CHANGE
         └─ RequestEventHandler sets EndTime = null

Step 3 — SQL INSERT / UPDATE
         └─ EndTime = NULL written to DB

Step 4 — afterSave (ours)
         └─ direct SQL UPDATE restores EndTime  ← after everything settles

beforeSave is the top slice of bread. afterSave is the bottom slice. RequestEventHandler — which steals the filling and writes it to the database — is sandwiched between them.

Sandwich assembled. Filling secured.

Chapter 4: The Recipe (Full Code Included)

Step 1: Register a Custom Model Factory

The form must instantiate MRequestKanban rather than MRequest directly. Otherwise our hooks never run. We use IModelFactory to tell iDempiere: whenever you need an R_Request object, use this class instead.

Register in OSGI-INF/requestkanban_model_factory.xml:

<scr:component xmlns:scr="http://www.osgi.org/xmlns/scr/v1.1.0"
    name="tw.idempiere.requestkanbanform.factory.RequestKanbanModelFactory">
  <implementation class="tw.idempiere.requestkanbanform.factory.RequestKanbanModelFactory"/>
  <property name="service.ranking" type="Integer" value="100"/>
  <service>
    <provide interface="org.adempiere.base.IModelFactory"/>
  </service>
</scr:component>

service.ranking=100 ensures our factory wins over the default. And don’t forget to include the XML in build.properties — if you skip this, the file won’t be packaged:

bin.includes = META-INF/,\
               .,\
               OSGI-INF/requestkanban_form_factory.xml,\
               OSGI-INF/requestkanban_model_factory.xml

Step 2: The Custom Model Class

public class MRequestKanban extends MRequest {

    private static final long serialVersionUID = 1L;
    private static final String END_TIME_ATTR = "Ninniku_OriginalEndTime";

    public MRequestKanban(Properties ctx, int R_Request_ID, String trxName) {
        super(ctx, R_Request_ID, trxName);
    }

    public MRequestKanban(Properties ctx, ResultSet rs, String trxName) {
        super(ctx, rs, trxName);
    }

    @Override
    protected boolean beforeSave(boolean newRecord) {
        // Stash EndTime BEFORE PO_BEFORE_CHANGE fires and RequestEventHandler erases it
        Object endTime = get_Value("EndTime");
        if (endTime != null) {
            set_Attribute(END_TIME_ATTR, endTime);
        }
        return super.beforeSave(newRecord);
    }

    @Override
    protected boolean afterSave(boolean newRecord, boolean success) {
        boolean ok = super.afterSave(newRecord, success);
        if (success) {
            Object stashedEndTime = get_Attribute(END_TIME_ATTR);
            if (stashedEndTime != null) {
                // Direct SQL — calling saveEx() here causes an infinite loop
                DB.executeUpdateEx(
                    "UPDATE R_Request SET EndTime=? WHERE R_Request_ID=?",
                    new Object[]{stashedEndTime, getR_Request_ID()},
                    get_TrxName()
                );
                set_ValueNoCheck("EndTime", stashedEndTime); // keep in-memory state in sync
            }
        }
        return ok;
    }
}

Step 3: Use the Custom Model in the Form

// Before — hooks never fire
MRequest req = new MRequest(Env.getCtx(), requestId, null);

// After — sandwich is active
MRequestKanban req = new MRequestKanban(Env.getCtx(), requestId, null);

⚠️ Warning: Don’t Order Another Sandwich Inside the Kitchen

Someone will inevitably ask: why not just call saveEx() inside afterSave?

Because you’d be ordering a delivery to the kitchen. The delivery person enters the kitchen, which triggers another save cycle:

afterSave → saveEx() → beforeSave → PO_BEFORE_CHANGE → afterSave → saveEx() → ...  💥

Infinite loop. Stack overflow. Server crying in the corner.

The correct approach: DB.executeUpdateEx() writes directly to the database table, completely bypassing the PO lifecycle. Then call set_ValueNoCheck() to keep the in-memory PO state consistent so subsequent reads see the right value.

The Menu (Summary)

Master Lei Says

I have long observed the iDempiere kitchen. Core events flow like water — their order fixed, immovable. To protect a single field’s value, one cannot fight the core head-on. One must move with its flow: stash before the storm in beforeSave, restore after the dust settles via direct SQL.

This technique is not limited to EndTime. Wherever an OSGi PO_BEFORE_CHANGE handler forcibly clears your field, the Sandwich Pattern applies.

Bread in position. Filling preserved. Every time.