Hi Diego,
My name is Fauzan, a developer from Indonesia. I've been using the Field Event Rules plugin you built for our internal iDempiere setup — it's been a fantastic tool, thank you for building it!
I wanted to share a feature I developed on top of it, driven by a specific business need we had.
The Need:
When a user creates a new record (e.g., AD_User), I needed the system to automatically create a related record in a different table (e.g., AD_User_OrgAccess) — without writing additional Java code.
What I Implemented:
I added a single new field AD_Target_Table_ID ("Target Table") to BXS_FieldEventAction. For the existing Target Column field (AD_Column_ID), I added a Dynamic Validation with this formula:
AD_Column.AD_Table_ID = COALESCE(NULLIF(@AD_Target_Table_ID@, 0), @AD_Table_ID@)
The logic is simple:
If Target Table is filled → the Target Column dropdown shows columns from the target table
If Target Table is empty → the Target Column dropdown shows columns from the source table (original behavior, unchanged)
This avoids adding a separate "target column" field — the existing AD_Column_ID field serves both purposes through dynamic validation.
Engine Changes (FieldEventRuleEngine.java):
I added two methods:
collectCrossTableAction() — collects all actions that have a Target Table set. Each action maps to one column + one value in the target table.
applyCrossTableRecords() — after all actions are collected, creates a new PO in the target table, sets all column values at once, and calls saveEx() wrapped in a savepoint to prevent transaction poisoning if the cross-table insert fails.
This feature only fires on PO_AFTER_NEW, since the source record's ID is only available after the INSERT is committed.
My Question:
Does this approach fit the architecture you had in mind for the plugin? I'd love to hear your feedback before polishing it further. If it's useful for the broader iDempiere community, I'd be happy to submit it as a contribution.
Thank you again for the great work on this plugin!
Best regards,
Fauzan