Server actions

Configuration entries of type Server action are used to configure functional modules of the censhare system, that are to be triggered manually by a user.

Introduction

Server actions, when activated, show up in the Server action menu of the client applications. Depending on the function of the Server action, it might become only visible when one or more assets (optionally of dedicated asset types) are selected in the client. These dependencies are hardcoded in the Server action and cannot be customized.

Overview

1. Standard header of all configuration entries with the internal name of the module, a description and a comment field, that can be used to keep track of the changes.

2. ServerActions contain a general setup section to define the rules and restriction of the manual triggering preconditions. The options are:

   • Server name: if empty, the ServerActions is made available to all ApplicationServers, otherwise it can be restricted to a specific server.

   • Enabled: this flag toggles the overall availability of the ServerAction.

   • Title and Description: these values can be overwritten. The title field determines the name, under which the ServerAction appears in the censhare Client ServerAction menu.

   • Version: this is a unique version number of the module. It is copied into the customized version, to ease the process of reviewing customization files after a system upgrade.

   • Permissions only for defined roles: restricts this ServerAction to users belonging to the selected roles. If empty, it applies to all roles.

   • Permissions only for defined client types: restricts this ServerAction to the selected censhare clients. If empty, it applies to all clients.

   • Permissions only for defined permission keys: restricts this ServerAction to those users, that contains the permission key in their privilege settings. The permission key can be any of the default keys or a custom key.

   • Shortcut: ServerActions can be bound to keyboard shortcuts. Refer to the tooltip of this option for details.

   All restrictions are summed up: a user can only use the ServerAction if he is fulfilling all criteria!

3. If a ServerAction performs on assets, an Asset update section is shown with the following options:

   • Update asset afterwards: this opens a dialog that allows to modify certain metadata, like workflow or domain, after the execution of the ServerAction. Applies only to those ServerActions that operate on assets. This feature is typically used to automatically change the status of an asset after executing the ServerAction on it.

   • Modification mode: this allows to define whether the asset should be displayed as checked out during the operation.

   • Process user: in case, the asset is to be displayed as checked out during the operation, this parameter allows to display any user of the userlist to appear as the checked out by user. It is recommended to create dedicated, invisible users for this purpose.

4. The final section in each configuration dialog finally contains the individual parameters for the functional configuration of that specific ServerAction.