In-line table edit support

Framework supports in-table object editing

• The solution concept
• Object-definition for in-table edit
• Server implementation
  • System reaction to change
• In-table edit example
• Warnings about the functionality

In-table edit is very fast and really convenient way how to update object values. Persons are used to edit fields directly in table from applications like MS Excel or similar table-editors and so the direct in-table field editing makes the application more user friendly.

The framework tables supports the editing including the right control and feedback about the change.

The solution concept

The list-view definition shall allow the object editing and each field that allows editing shall allow it separately as well.

The rights controlling if user is allowed to edit the field could be defined globally for the whole object line or separately for each cell individually.

AyMINE server defined common method for storing the update. However, the in-line edit does not call post-update object method and so it could be necessary to override the default method and used the object-specific object update.

Object-definition for in-table edit

The list shall enable the editing using the editable attribute for list and fields

If the editable is used in the list-related attributes, conditions is used for all rows in the list. The editable attribute could be a Boolean-type value (only true makes sense because false is the default) or JS method with the right condition

The framework support in-table editing only for the value types:

• Single line text
• Single-value selection from the system-defined or user-defined counter (including icon selection)
• Multiple-value selection from both system or user defined counter
• Check-box (yes/no values)
• Numerical value

Other value types are not currently supported. Particularly it does not support formatted text editor and some less-common styles like colour and meter.

Server implementation

After the field edit the table calls the server method. By default, the method objectName.updateFromList is called.

The default method could be overwritten by the object (in the back-end object implementation) or using the update attributes in the view definition. The view update field definition allows condition that verifies the right of the update after the value change but before calling the server

Recommendation: For code readability and better user experience we recommend using always updateFromList method that is called by default and override its implementation by backend. (The user experience requires always to check the edit rights during the field loading and don't allow update of fields which change might later be rejected.)

System reaction to change

The server method should confirm or reject the change.

• If the change is confirmed table changes colour of the edited text to the confirmation colour (green in the default visual style) so that user has visual confirmation that the change was accepted
• If change is rejected:
  • Application returns value to the original
  • Colour of the text is switched to the warning colour (red in the default visual style)
  • User warning with the message from server appears

In-table edit example

List editable field definition (The example is from the Business Area object)

"list view Name":{
   "attributes": {
      "name":{ 
         "treeIndent":true,
         "rowIcon":"obj.icon",
         "editable":"obj.responsibleID = user.ID"   // Only person responsible for are could edit its name
      },
   }
}

The following example defines right to edit object for complete object row (The example is taken from the Requirement object):

"abstract":{
   "parameters":{
      // condition who can edit requirement in the table
      "rowEditable":"obj.responsibleID == user.ID && obj.status == 'A' && ['S0','S1'].includes(obj.lifecycleStatus) && obj.editLock == 0"
   },
   "attributes":{   
      "systemType":{},                // not-editable field
      "lifecycleStatus":{             // not-editable field
         "visible":true, 
         "icon":"step" 
         }, 
      "name":{ "editable":true },      // Editable field
      "priority":{ "editable":true },  // Editable field
      "shortDesc":{ "editable":true }, // Editable field
      . . . 
   }
}

The stock operation (am module) uses its own method for in-table edit response:

"operList":{ 
   "extends":"abstract", 
   // updateStockAsset is called after the field edit instead of default updateFromList method
   "update":"server.amStockOper.updateStockAsset",  
}

The server method implementation for in-table update:

public static function updateStockAsset(Command $command): Response
{
   try {
      $ch = $command->getTableChangeData();   // Default method the provides object with changed fields

      // Makes controls that user can update field
      $checkObj = $command->attrVal('masterObject');
      if ($checkObj !== __CLASS__) 
         return Response::InternalErr(__METHOD__, 'err_UpdateNotAvailable');
      $stockOperID = $command->attrVal('masterID');
      $reject = static::checkRightsInt($stockOperID, operC::update, $oper);
      if ($reject) return $reject;

      // Makes update
      . . . 
   }
}

Warnings about the functionality

The in-table object edit has almost the same risk as multiple object update because the method without further back-end implementation might over skip the related business functionality.

Check warnings related with the multiple object update here.