Skip to main content
Matrix42 Self-Service Help Center

Create Custom Delete Behavior

  1. Last updated
  2. Save as PDF

Summary

By default the Delete Objects dialog doesn’t handle removing of custom mandatory references. For these situations a custom delete behavior can be used. Examples and guide to create a custom delete behavior are described below. Please use the enclosed samples solution, SQL scripts and update package as described to check these examples with the Workspace Management Console.

Issue

Let’s say we have created a custom data definition Cust_SPSUserPetClass which has a [N to 1] reference to the Person configuration item. As a result we have the following structure:

DataSchema.png

You can use this Data Schema Package to import this data schema via the Workspace Management Console.

Then let’s populate this custom data definition with the custom data. Please create a person for testing purposes using the Workspace Management Console. Take the Last Name of the record and use it in the Populate Custom Data SQL script. It will add some records to the Cust_SPSUserPetClass data definition. After that trying to delete the created person will cause the exception of the Delete Objects dialog.

Solution

As it was stated above the solution here can be creation of the custom delete behavior.

Step 1. Pre-check

Before implementing the custom delete behavior please make sure that:

  1. the configuration item you want to handle is included into the del_GenericDelete action and removed from all other delete actions. Please use Administration -> Services & Processes -> Action tabulator to find delete actions and verify the configuration item you need to handle.
  2. there is no existing delete behavior assigned to the configuration item. To verify this use the Verify Delete Object Behavior SQL script. If the delete behavior already exists it is strongly recommended to inherit your own class from the existing that is returned by the SQL script. This will not allow to lose any existing delete logic. Also all the custom attributes (SchemaTypeDeleteBehaviorDialogExtension and/or ActionValidator) if they exist in the original class should be copied over too.

Step 2. Registration

The delete behavior is a .NET class from any assembly that requires to be located in the \Web\bin sub-directory of the Matrix42 root application folder. This class should support Matrix42.BizLogic.Client.CascadeDelete.ISchemaTypeDeleteBehavior interface and it is advisable to inherit it from the Matrix42.BizLogic.Client.CascadeDelete.SchemaTypeDeleteBehavior class. After creation of the new class either inherited from original delete behavior or from SchemaTypeDeleteBehavior it needs to be linked to the configuration item. You may use the Register Delete Object Behavior SQL script where the configuration item’s name, delete behavior assembly and type should be populated. Make sure that IIS server is restarted after execution of the SQL script.

Step 3. Implementation

The implementation of the custom delete behavior depends on the logic you need to put in it. For the examples below please refer to the Samples Solution. Please extract the archive into the Workspace Management Console root folder.

Custom removal

In the case described above overriding the CustomObjectDelete method can be used to clean custom data. See example in the RemoveUserBehaviorSample1 class. It performs cleaning of the potentially orphan objects before removal the main object itself.

Mapping related objects

Delete behavior provides functionality to find and show related objects before removal procedure to delete them and/or find blockers that prevent deletion.

In your class you can override the GetRelatedObjects method where you can return objects that depends on the object about to delete. They will be deleted too. More sophisticated logic can be used when overriding the GetRelatedObjectMappers method. It returns the DeleteObjectRelatedObjectsMapper collection. The DeleteObjectRelatedObjectsMapper contains the RelationExpression property using which the delete dialog searches objects related to ones about to delete. Property BlockDelete shows is the related objects are blockers for deletion the original one and need to be handled manually.

See example in RemoveUserBehaviorSample2. The RelationExpression is T(SPSActivityClassBase).Initiator which means before deleting a person all objects (tasks) where the selected people to delete are initiators will be found and if BlockDelete equals true – the delete objects dialog will stop removal procedure until there objects are deleted or relocated. If BlockDelete equals false the related objects will be deleted too.

Adding custom logic

Delete behavior also provides the ability to handle events before and after the deletion is executed.

For this you can override the following methods:

  • void BeforeDelete(DeleteObjectsOperationExecutionContext executionContext). Occurs before the deletion is executed. The execution context contains information about related objects and objects to delete. Also it holds information from the delete dialog extension (see below).
  • void AfterDelete(DeleteObjectsOperationExecutionContext executionContext). Occurs after the deletion is executed.
  • bool CustomObjectDelete(DeleteObjectInfo deleteObject). Occurs before deleting each object. if returns true – the standard removal procedure for the object will not be performed.

See example in RemoveUserBehaviorSample3. The CustomObjectDelete method returns true which means the standard removal procedure will be skipped. Actual objects deletion is implemented in the AfterDelete method.

Custom user interface

Delete behavior can include user interaction before deleting objects. As an example the original remove user dialog contains (when required) reassigning controls which can move related objects to another reference and the objects to delete will not have blockers.

For that the SchemaTypeDeleteBehaviorDialogExtension attribute should be added to the custom delete behavior class containing the url to the custom control that supports Matrix42.Web.UI.Controls.Tasks.Delete.IDeleteDialogExtension.

See example RemoveUserBehaviorSample4 and RemoveDialogExtension.ascx. The control should return (if needed) 2 java-script functions (they should be included into the control or related scripts):

  • ValidateFunctionName – to validate the custom dialog extension’s controls
  • DeleteParamsFunctionName – to return result of user interaction (in JSON format preferably). This result will be held in the ExtensionDialogParams property of the DeleteObjectsOperationExecutionContext. In the BeforeDelete/AfterDelete methods it can be deserialized and used.

Custom validation

Delete behavior can provide custom validation before the delete object dialog is shown. For that the ActionValidator attribute needs to be added to the class.

See example RemoveUserBehaviorSample5. The delete behavior contains validator that rejects all the attempts to remove objects.