DynamicForm.saveOperationType doesn't become update after saveData

[claudiobosticco]

SmartClient Version: v11.1p_2017-12-10/AllModules Development Only (built 2017-12-10)

Chrome on OSX High Sierra

Hello, I've found a bug where the saveOperationType of a form doesn't change from add to update after a save operation.
It happens when the primary key field is visible in the form.

Please try this test case (I've run it in the #fetchOperationFS showcase sample):

isc.ListGrid.create({
    ID:"dsListGrid", 
    width: "100%",
    height: "100%",
    autoFetchData: true,
    dataSource: "supplyItem" 
});

isc.DynamicForm.create({
    ID:"dsForm", 
    width: "100%",
    height: "100%",
    dataSource: "supplyItem",
    fields:[
      {name: "itemID"},
      {name: "itemName"},
      {name: "SKU"},
      {name: "category"},
      {name: "unitCost"}
    ]
});

isc.Button.create({
      ID: "saveButton", title: "save", autoFit: true,
      click: function () {
         dsForm.saveData();
      }
});

isc.VLayout.create({
     ID: "vLayout", overflow: "auto",
     width: "100%",
     height: "100%",
     members: [
       saveButton,
       dsForm,
       dsListGrid 
     ]    
});

Type and save some data, you'll see am add in the rpc tab of the dev console:

{
    dataSource:"supplyItem", 
    operationType:"add", 
    componentId:"dsForm", 
    data:{
        itemName:"test", 
        SKU:"1234", 
        category:"1", 
        unitCost:1
    }, 
......

then modify something, for example unitCost, and save:

{
    dataSource:"supplyItem", 
    operationType:"add", 
    componentId:"dsForm", 
    data:{
        itemName:"test", 
        SKU:"1234", 
        category:"1", 
        unitCost:6, 
        itemID:3969
    }, 
....

another add is performed. It happens also if the itemID form field has canEdit:false.

It doesn't happen if the itemID field is not declared or has showIf:"false"

[Isomorphic]

If the primary key can be edited, an "add" is what would be expected, unless you're expecting that either an add or an update is issued based on whether there is an existing record? We don't try to do that, since we don't know the user's intent - not editing the primary key may be an attempt to add a new record but they simply forgot to enter a new key, in which case an error message (collision with existing record) is desirable rather than proceeding with overwriting fields of an existing record.

[claudiobosticco]

OK, sounds fair, but I've noticed the same behavior even with showIf:"false", and also with canEdit:false (on the form item and also on the dataSource field)

[Isomorphic]

There again, if you've included the field in the form and just created a new record with it, we don't have enough information about your intent to be sure that switching from "add" to "update" is the right thing. The fact that there's a field for the PK strongly implies that you're manipulating it in some way - perhaps by generating it or taking some other programmatic approach.