You definitely won’t be able to do that client-side, the Duplicate Button is purely focused on that Entity and will only duplicate those records, not any child records.

One way you would achieve your requirement is through a Customization with Developer Studio basically doing the following:

1. Create a new Command (button) at shift level called something like “Duplicate with Breaks”
    
2. Make that command open a dialog (or assistant, but that’s a bit overkill) where you get the user to put in the new updated values from the duplicated (for example a different employee ID, or a different shift start/shift end)
    
3. Once the values have been provided by user, have the command call a newly created Projection Action with a PLSQL Implementation, sending all the data from both the source row (in order to identify any existing children) and the user-specified data (in order to create the new header with new data)
    
4. Have the PL/SQL Method run your business logic (a: Create the new shift header with the values provided by the user, b: check if the source row has any breaks, c: Create the breaks (if they exist) for the newly created shift header

Hi ​@SimonTestard 

Thanks for your answer. I will definitely try this out what solution you told - creating new button with PLSQL implementation if there are no other way.

But still I am looking for some solution if I found the way to Override Default_CRUD_Copy___ to do that.

Thanks

Mizanul

Good idea in theory, but Overriding Default_CRUD_Copy___ likely won’t work because those Default methods are about retrieving the default values that get duplicated client side when you click the duplicate button.

Effectively, this is about determining what data in which fields is retrieved in the newly created dirty (unsaved) row (upon clicking the duplicate button)

It is called BEFORE saving and therefore cannot be used to create breaks because creating the breaks requires the parent header to exist in the database, and it doesn’t exist until the duplicated dirty row is saved ;)

Thanks again ​@SimonTestard for a better insight