need help with nonstandard duplicate record handling

58 views
Skip to first unread message

reua...@gmail.com

unread,
May 11, 2021, 6:52:55 AM5/11/21
to iDempiere
Hello community,

I have a table that has a unique restraint that includes a number of columns.
What I now need to achieve is: Instead of throwing an error when the user tries to save a duplicate new record I want iDempiere to load the existing record with the same properties and use that instead of the one that could not be saved. 
That would mean: 
- in a tabbed window: load the existing record into the tab (or switch to the record item if already in the list
- in a quick editor: enter the ID of the existing record into the GridField from where the QuickEditor was launched.
I am a bit a loss now because AFAIK the before new event handler does not know anything of the gui while the gui aware callout mechanism can not be used to modify the onsave behaviour. Also to achieve a consistent behavior there should be an analog mechanism when the save is invoked by a process instead of a user interaction.
I am aware that I haven't thought that perfectly through but maybe somebody has already solved that riddle? 
As always thanks for any helpful hints and comments.

Andreas



reua...@gmail.com

unread,
May 12, 2021, 6:12:44 AM5/12/21
to iDempiere
Update: I have now decided to narrow the scope of the customization and only cover record creation from a grid field.
Instead of tampering with the QuickEdit feature I am going to create a custom DataType. I can implement my requirement as part of the custom dialog for my datatype.

That said: while working on the code skeleton of that solution I got the Idea that development time could be considerably reduced if we made the quickedit dialog available for customization as an OSGI service. Here are the benefits that I can see right now (comparing custom datatype QuickEdit osgi service)
  • Dialog field setup in application dictionary instead of code allows customization by System user.
  • Dialog is accessible through the familiar context menu -> improved user experience.
  • No custom editor required, No Custom Datatype setup -> faster development. 
What do you guys think?

Andreas


Reply all
Reply to author
Forward
0 new messages