This document intends to clarify the approach taken to address the need of a customer to delete module versions and entities, usually to fulfil compliance or strategic goals.

DISCLAIMER: Completing this solution will permanently delete the entities related to the specific module, which will cause a permanent loss of the data contained in these structures. Therefore, it is not possible to recover this data.

DBCleaner integration

The DBCleaner API is the component responsible to achieve this. It allows a permanent information removal upon customer request and covers most components within an OutSystems module, such as entities and module versions.

The documentation for this component can be found in DBCleaner_API and it is important to understand the proposed solution to address this issue.

The solution

For the proposed solution of deleting module versions and module entities to comply with audits, the DBCleaner API component already has the needed tools to perform these tasks.

As for removing server modules, the customer can use the ModuleVersion_DeleteAll command to remove all versions of a module.

Regarding specific data removal, the customer can use the Entity_DropTable command on all entities belonging to the desired Module. This command has been reworked in the last few months to delete most of the info related to an entity, including tenant views, multilingual tables, and similar components. These specific changes are available from version 11.14 onwards.

Practical suggestion

With all things considered above, we will guide you upon producing the OML solution to answer the above-mentioned issues.

OML Preparation

For the construction of this OML, it is required to create a blank screen and fill some Preparation steps in order to be able to accomplish all tasks.

The aggregators should be respectively filled with the indicated sources. Therefore, the GetEspaces aggregator should have the Espace entity as a source, and the same respective for all other aggregators. The List_Oldest action, that belongs to the DBCleaner_API, should also be present in there, but it is only required if there is a need to check the versions.

With all this being done, we now have all the right tools to construct all the actions in order to achieve the goals.

Constructing the screen

The main screen should have two tables. One to display the available Modules to delete and one to delete entities from a specific Module.

The pre-created GetEntities, GetEspaces and GetModules should serve as an entry point to create the tables.

This creation should allow for an easy-to-see approach that should be able to cover both cases. The list in between is the version list for a specific Module, but that is not mandatory.

Action set-ups

To delete all version from a Module, we need to create a Server Action within the screen.

This server action should include the ModuleVersion_DeleteAll action from the DBCleaner_API.

For arguments, we add a destination to the Drop button in order to run this function, passing the Module as an argument.

While configuring the ModuleVersion_DeleteAll action, the configuration should be the following:

Note that the MaxNumberOfVersions parameter can be as high as how many versions you need to delete.

With this, we should by now be able to delete versions based on a Module.

To delete all entities from a Module, the steps are quite similar.

You should create a DropTable action (in the screen) that is directly linked to the Drop button as a destination. This destination should take the Current Entity as an argument.

The Entity_DropTable action, from the DBCleaner_API, should take this entity and pass its Id as an argument.

 

With the combination of these two approaches, we should now be able to delete module versions and entities on demand.

We hope this will answer your needs. If not, feel free to ask question and we will come back.