Disable copy/paste/cut features in input widgets in OutSystems applications

Cut, copy and paste define a paradigm in human-computer interaction used to transfer content (text, data, files, objects) from one point to another.

Certain content can be cut, copied and pasted from different locations within the same document, between different documents, or even between different applications.

However, for security, integrity or other business requirements, sometimes, we need to disable these capabilities (sometimes one of them, sometimes all of them).

To solve this problem, we will show an example in which the blocking functions will be defined one for each case: copy, paste and cut.

In the example we will implement the functions in an independent module, which is generic and agnostic to the business (recommended to remain in the Foundation layer).

This implementation will have three Client Actions, one for each case (you can also implement just one Client Action, in which we define in the input which of the three functionalities we want to block, dealing with the necessary cases within the flow of the respective Client Action). All of these Client Actions must be defined as public if they are implemented in a generic module and with the aim of reuse:

Fig 1 — Definition of Client Actions to disable Copy/Paste/Cut functionalities

These Client Actions require an input to be able to affect the desired widget: the WidgetId. To do this, we define the input with the Text type and mandatory in all of them:

Fig 2 — Definition of the input to receive the Widget Id where the features will be disabled

The input that we added to each of the Client Actions can now be used in the JavaScript code that will disable the corresponding functionality of each action.

To do this, in each of the Client Actions we must add a JavaScript node to their flows (which we can call “Disable” + feature_name), adding to each of these nodes an input parameter called “WidgetId”, of type Text:

Fig 3 — Creating a JavaScript node with the input parameter to obtain the WidgetId

The code that will be inserted into each JavaScript node will be different, according to the functionality of each node and the respective Client Action in which they are inserted. The code to be inserted into each node will be as follows:

Disable copy:

document.querySelector("#" + $parameters.WidgetId).addEventListener("copy", function(event) {
    event.preventDefault();
}, false);

Disable cut:

document.querySelector("#" + $parameters.WidgetId).addEventListener("cut", function(event) {
    event.preventDefault();
}, false);

Disable paste:

document.querySelector("#" + $parameters.WidgetId).addEventListener("paste", function(event) {
    event.preventDefault();
}, false);

Fig 4 — Example of JavaScript code implementation to disable Paste

After inserting the respective codes into the nodes, we must map the input of each of the Client Actions to the input parameter of the respective JavaScript node. After this operation, we can publish the module where we are developing the features:

Fig 5 — Mapping the Client Action input that transports the WidgetId to the JavaScript node input parameter

Now we must test. To do this, we use a module on the End user layer with text inputs that we can disable (note that we can perform these operations at the level of CW modules in Blocks that have associated inputs).

We created three different inputs on a web screen, one to test each of the features separately (this way we guarantee that they work independently of each other). We must also import the Client Actions through the “Manage Dependencies” functionality of Service Studio:

Fig 6 — Test web screen with three separate inputs for each case

Now, we must associate in the “OnReady” event of the page the Client Actions that we import and map the Ids of their inputs with the Ids of the Input Widgets that we create on the screen (if it is a Block, it must be in the “OnReady” event of the Block, since it is at this stage of the life cycle that we have the widgets “assembled” and with their respective Id’s):

Fig 7 — Use of Client Actions with the functionalities provided in the “OnReady” event of the test web screen with respective mapping of the Ids of the input Widgets to the inputs of the Client Actions

Finally, publish and test!

Note that we can use these Client Actions in any other Client Action, it does not need to be in the “OnReady” event. We just have to be aware that the functionality will only be available when the Client Action in which the functionalities are inserted is executed.

If you want to check the implementation proposed in this article, you can install the following Forge component: https://www.outsystems.com/forge/component-overview/18169/disable-cut-copy-paste-o11

As always, I hope this article can help someone on their OutSystems platform journey!