Scripts on Events

Using scripts on events

Product line

Standard

Expert

Operating mode

CLOUD ABO

ON-PREMISES

Modules

Services & CRM

Budget & Phases

Purchases

Resource Planning

Business Intelligence

Created: 03.12.2007

Updated: 15.03.2024 | Added vtcapp.DisabledEvents().

Scripts can be started by certain changes, so-called events. As soon as such a change occurs, the stored script runs automatically, without additional user interaction.

An event script is created like a normal script via Settings > Reports & Scripts > Script: Right-click New > Script.

designation

Any designation can be entered here. Event scripts do not appear in a menu.

Platform

From version 6.6. This field is used to indicate whether it is a Python Script or VBScript When executing the scripts, a distinction is made according to the platform setting whether VB or Python is executed.

Classes

Nothing can be entered here for event scripts, otherwise the event script would appear in the corresponding menu, which is undesirable.

Condition

This field has no relevance for event scripts. It only controls the visibility of normal scripts in the menu.

Applicable to individual objects / Applicable to lists (containers)

Not required for event scripts.

Event script for

Scripts can be registered on the following types of events:

New: The script is started as soon as an object of the designated class (see table below) is created anew.
Changed: The script is started as soon as there is a change to an object of the designated class (see table below) and a specific field (see below).
Login: The script is started as soon as a user logs into Vertec ( argobject = logged-in user).
Delete: A difference from the other events is that the event script is called during the delete process, but just before the actual delete (so that the original state with all connections still exists).
Errors from delete scripts are written to the log, but otherwise ignored. This does not block deleting.
It is not possible to prevent deleting in the delete script. This is because several delete scripts can be defined in a class hierarchy. In such cases, it could happen that one script makes changes during delete, and a subsequent script then prevents deleting, resulting in an inconsistent state.
Business logic: These scripts run at specific times, given by business logic. As a first option, the business logic Event Calculaterate was introduced. This allows custom logic to be executed to calculate the rates of a service. This event, in this case the Calculaterate, is entered as the field name.

As usual with event scripts, the script is called only when all other logic has expired. In the case of Calculaterate, this means that the built-in tariff logic, taking into account rate table, etc., runs first and sets the rate as before. Only later does the event script come and overwrite the value calculated by the built-in business logic.
As usual, the affected service is shown in the event script as argobject available.

Classes

Specifies which classes the script responds to. No class is required for event scripts of the type Login.

Fields

Here you can specify a single field on the class, whose change you want to react to. Specify a field is only useful for event scripts of the type Modified.

If you want to respond to more than one field, you can specify them one after the other, separated by commas. You can also specify custom field items by simply specifying the name of the custom field item.

If no field is specified, the script responds to all fields, i.e. to all changes made to that class. This should not be done under any circumstances, as this can result in massive performance loss.

event scripts cannot be registered on derived attributes (calculated fields).

Event	Designate class	Designate fields
New	Yes	no
Amended	Yes	Yes
Log in	no	no
Delete	Yes	no

Extended user rights

A Script can be Extended user rights be accepted.

Arguments for member and event in event scripts

An event script should know which event triggered it on which member. This makes it easier to handle different events with the same script. The global variable args is available for this purpose:

args.eventmember contains the name of the triggering member
args.eventtype contains the type of event: 'change’, 'create’, 'login’, '' (empty string for delete)

Example:

if args.eventmember == 'active’:
    argobject.note = 'Active has been changed’

if args.eventmember == 'project leader’:
    argobject.note = 'PL has been changed’

Check UI if dialogs are shown

If dialogs are displayed shown in an event script, it must always be queried whether the client is capable of showing user-specific dialogs, i.e. whether the client is one of the full-featured apps.

This is done by means of: OCL operator .hasGui, which True or False returns.

It is important that no dialogs are shown if this is not possible on the client being used, as this may block Vertec or lead to undesirable results: msgbox() for example, gives OK back if the dialog cannot be shown. If it also had a cancel button and the code assumes that a user is active OK has clicked, data may be changed, deleted, etc., unintentionally.

Turn off scripts on events

When using scripts on events, note the following:

Complicated calculations when data changes can slow Vertec’s performance.
Endless scripts that invoke themselves over and over again can cause Vertec to crash.
Scripts that interfere with the functionality of Vertec (e.g. setting an hourly rate on a newly generated service) can lead to an opaque behavior of Vertec.

For these reasons, it is possible to start Vertec with a /noevents parameter. This prevents any event scripts from being executed in Vertec.

To temporarily prevent the execution of event scripts within other scripts, there is the method vtcapp.DisabledEvents() .