remove

Deletion in the system works as a cascade. The system identifies all dependent classes (tables) and their dependency types. Then, it searches these classes to see if there is any data dependent on the record being deleted.

A dependency can be parent-child, in which case deleting a record will delete all its dependent records, or a reference dependency where the record is used in other entities as a lookup; in the latter case, those fields are cleared.

Dependencies take into account hierarchical tables, and for all dependent data, their own dependencies are also sought.

Such deletion requires confirmation, for which the parameter confirm=true must be passed. If the parameter is not passed, then after searching for dependencies, the system returns a UserError of type needConfirm (code=10) and passes an object with information about all dependencies in the data.

Code 10 is handled specifically by the front-end automatically, showing a confirmation dialog with the text and layout specified on the back-end. You can use needConfirm in your custom methods.

Deletion may be prohibited at the class/client object profile level (editable/remove_command).

The system uses a soft deletion mechanism, meaning data is not actually removed but marked with a timestamp. The core builds all queries such that a condition to check the deleted field is inserted everywhere (including joins).

Input Parameters. IAPIQueryParams Interface

The id of the record to be deleted and the boolean field confirm=true.

Output Parameters. IAPIResponse/IError Interface

In case of an error, the method will return an error object - an instance of UserError/MyError.

In case of success, the method will return the id of the deleted record in the data object of the UserOk instance (res.data.id).