NABUCCO Script Center Manual 1.1 - PRODYNA

NABUCCO

Script Center Manual (Version 1.1.0)

ContactPRODYNA AG Ludwig-Erhard-Straße 12-14 65760 Eschborn T +49 69 597 724 – 0 F +49 69 597 724 – 700 [email protected] https://www.prodyna.com

Personal ContactDr. Jens Bruhn Lead Architect Portal Solutions PRODYNA AG Ludwig-Erhard-Straße 12-14 65760 Eschborn M +49 176 178 70 220 [email protected]

mailto:[email protected]

mailto:[email protected]

Table of Contents

1. Introduction 3 ........................................................................................................................................................

2. Installation 4 .........................................................................................................................................................2.1. Properties 4 ......................................................................................................................................................................

2.1.1. portlet.properties 4 ....................................................................................................................................................

2.1.2. portal-ext.properties 7 ..............................................................................................................................................

2.2. Installation Procedure 8 .................................................................................................................................................

2.3. Upgrade from Version 1.0.0 8 .........................................................................................................................................

2.4. First Step 9 .......................................................................................................................................................................

3. Script Management 11 .........................................................................................................................................3.1. Overview 11 ......................................................................................................................................................................

3.1.1. Breadcrumb Navigation 11 .......................................................................................................................................

3.1.2. Script-independent Actions 12 ................................................................................................................................

3.1.3. Summary Tabs 12 ......................................................................................................................................................

3.2. Create 16

3.3. Read 18

3.4. Update 19

3.5. Delete 19

3.6. Copy 20

3.7. Import 20

4. Lifecycle Interception 21 .....................................................................................................................................4.1. Overview 21 ......................................................................................................................................................................

4.2. Create 22

4.3. Read 23

4.4. Update 23

4.5. Delete 23

4.6. Variables 23 ......................................................................................................................................................................

5. Scheduling 25 ........................................................................................................................................................5.1. Overview 25 ......................................................................................................................................................................

5.2. Create 26

5.3. Read 27

5.4. Update 27

5.5. Delete 28

NABUCCO Script Center – Manual (Version 1.1.0) � © PRODYNA AG 2016 – All rights reserved 1

.........................................................................................................................................................................................

...........................................................................................................................................................................................

.......................................................................................................................................................................................

.........................................................................................................................................................................................

............................................................................................................................................................................................

........................................................................................................................................................................................

.........................................................................................................................................................................................

............................................................................................................................................................................................

.......................................................................................................................................................................................

.........................................................................................................................................................................................

.........................................................................................................................................................................................

............................................................................................................................................................................................

........................................................................................................................................................................................

.........................................................................................................................................................................................

6. Output Processing 28 ...........................................................................................................................................6.1. Console 29

6.2. Log 29

6.3. Document 29 ....................................................................................................................................................................

6.4. Email 31

6.5. Web Content 32 ................................................................................................................................................................

6.6. None 33

7. Permissions 34 ......................................................................................................................................................7.1. Portlet Permissions 34 ...................................................................................................................................................

7.2. Service Layer Permissions 34 ........................................................................................................................................

7.2.1. Package Level Permissions 34 .................................................................................................................................

7.2.2. Script Permissions 35 ...............................................................................................................................................

7.2.3. Lifecycle Interception Permissions 36 ....................................................................................................................

7.2.4. Schedule Permissions 36.........................................................................................................................................

NABUCCO Script Center – Manual (Version 1.1.0) � © PRODYNA AG 2016 – All rights reserved 2

......................................................................................................................................................................................

..............................................................................................................................................................................................

..........................................................................................................................................................................................

...........................................................................................................................................................................................

1. Introduction NABUCCO Script Center (NSC) is a generic solution for scripting in Liferay portals. In this context, NSC provides additional features on top of Liferay’s Script Engine. These features start with script management, continue with script scheduling and the registration of scripts as model listeners, and end up with the formatting of reports and script execution results. Especial-ly script scheduling and the application of scripts as model listeners open up new application areas for scripting in Liferay.

This manual provides all relevant information to install and apply NSC in portal environments. Chapter 2 Installation address-es the installation of NSC including a discussion of all configuration settings. An overview of general script management aspects is provided in chapter 3 Script Management. The subsequent chapters 4 Lifecycle Interception and 5 Scheduling sep-arately discuss two application areas of scripting which are new and specific to NSC. The different options to let NSC process the output of script execution are presented in chapter 6 Output Processing. Script output processing is a convenience func-tionality of NSC. Finally, all permission related aspects are summarized in chapter 7 Permissions.

NABUCCO Script Center can be obtained either from Liferay Market Place or from the NABUCCO Script Center homepage:

• Liferay Market Place : https://www.liferay.com/marketplace/-/mp/application/55972350

• NABUCCO Script Center : https://www.prodyna.com/scriptcenter

Besides the core plugin, sample scripts and this manual as well as additional information can be found on the NSC home-page.

Lots of fun with scripting!

NABUCCO Script Center – Manual (Version 1.1.0) ! © PRODYNA AG 2016 – All rights reserved 3

https://www.liferay.com/marketplace/-/mp/application/55972350

https://www.prodyna.com/scriptcenter

2. Installation

The installation of NSC can be performed very easily by simply placing the war- or lpkg file into the deploy folder of a Lifer1 -ay installation. There are a few configuration options supported through configuration files . Some of these have major im2 -pact on the general behavior of NSC and cannot be changed after installation without manual intervention. Those entire con-figuration options are preconfigured with default values considered appropriate for most application scenarios. Nevertheless, those configuration options should be considered before first installation. Therefore, section 2.1 presents the supported con-figuration options. The installation procedure itself is discussed in section 2.2. Section 2.3 contains remarks and explanations which are relevant for those who upgrade from version 1.0.0 of NSC. Finally, section 2.4 describes the first steps after instal-lation in order to get started using NSC.

For a new installation of NSC based on recommended, default settings the installation procedure is described in section 2.2 Installation Procedure.

2.1. Properties The general behavior of NSC can be configured with respect to different aspects at deployment time. Certain aspects can only be configured on first installation and must not be changed afterwards. The configuration can be performed through the two files portal-ext.properties and portlet.properties. Both files can be found in the folder WEB-INF/classes within the plugin war file nabucco-script-center-portlet-1.0.1.war.

The following aspects can be configured through properties within the file portlet.properties

− Initial Script Import – NSC is delivered with two sample scripts which are imported on installation. The corre-sponding configuration option for the initial script import is explained in section 2.1.1.1.

− Group Mode – NSC either saves script in the context of companies or sites. Section 2.1.1.2 shows how this can be configured.

− Script Deletion Mode – The deletion of a script has impact on potentially associated schedules and registered lifecycle interceptions. The corresponding behavior can be controlled through the configuration option described in section 2.1.1.3.

− Schedule Execution Mode – Script executions in the context of schedules might overlap. The corresponding be-havior can be controlled through the configuration option described in section 2.1.1.4.

− Output Processors – NSC is delivered with a set of output processors. The set applied within an installation can be controlled through the property discussed in section 2.1.1.5.

Within the file portal-ext.properties the following aspects can be influenced

− Model Listener Manager – NSC is registered as model listener on application startup. The corresponding imple-mentation can be changed as discussed in section 2.1.2.1.

− Supported Model Classes – NSC by default supports all model classes identified on startup. The set of supported model elements can be influenced as described in section 2.1.2.2.

2.1.1. portlet.properties

The behavior of NSC can be influenced through portlet properties. Each of the following subsections addresses one particular aspect.

Depending on the source NSC is obtained from.1

portal-ext.properties and portlet.properties2


2.1.1.1. Initial Script Import

NSC is delivered with a set of sample scripts. These are imported on first installation. There are three aspects of import be-havior which can be influenced through corresponding properties. First of all the set of scripts to import can be defined through the property script.import.files. Secondly, the target company of the import can be set through the property scrip-t.import.company.id. Finally, the property script.import.user.id can be used to set the owner of imported scripts.

− script.import.files – This property contains a comma-separated list of file names. These file names correspond with NABUCCCO Script Center Archives being part of the plugin to install. Archives can be found within the plugin 3

war-file nabucco-script-center-portlet-1.0.1.war inside the folder

WEB-INF/classes/META-INF/scripts

The property can be left empty if no scripts should be imported on installation. If additional scripts should be im-ported, the property can be extended. It would, e.g., be possible to download additional scripts from the NSC home-page , place them into the folder mentioned above, and finally adjust the property value. NSC will install the addi4 -tional scripts for this case. The default value of this property is

Deactivation of Users Accounts on Inactivity.1.0.0_0.nsa,

Identification of expiring Web Contents.1.0.0_0.nsa 5

This leads to the installation of the two scripts Deactivation of Users Accounts on Inactivity and Identification of expiring Web Contents. Both scripts can also be downloaded from the NSC homepage.

− script.import.company.id – Scripts are imported into the default company of a Liferay installation by default. This property can be set to the identifier of a distinct company if the initially imported scripts should be stored in 6

the context of the corresponding company. This property is empty and commented out by default.

− script.import.user.id – Scripts are imported with the user account specified through the portal property default-.admin.screen.name by default. As fallback solution in case of a deletion of that account, the default user account of the selected company is taken . The property script.import.user.id can be used to provide an identifier of a user 7

account which should be applied as owner of the imported scripts. This property is empty and commented out by default.

2.1.1.2. Group Mode

A group is stored for each model element of NSC. This group determines the context of the particular model element. 8

Amongst others, the group relation is relevant in the context of permission checking and for the selection of scripts in the initial overview.

Different usage scenarios were considered during the realization of NSC. In certain scenarios it might be meaningful to store scripts centrally, i.e., without any relation to a certain site. In other scenarios it might be meaningful to support site-specific scripts. The configuration option group.mode was added in order to support both types of scenarios. The following two values are supported for the property.

− COMPANY – All group identifiers stored by NABUCCO Script Center are set to the current company group identifier.

nsa files3

https://www.prodyna.com/scriptcenter4

No line break in properties file.5

companyId of com.liferay.portal.model.Company6

com.liferay.portal.service.UserLocalServiceUtil.getDefaultUser(<script.import.company.id>)7

like script, schedule, or lifecycle interception8



− GROUP – All group identifiers stored by NABUCCO Script Center are set to the current group identifier . 9

For both cases, the actual value of the property only applies to identifiers used for NSC specific model elements. Group iden-tifiers of, e.g., journal articles being created or manipulated by scripts are not affected.

!

The default value of the property is COMPANY.

2.1.1.3. Script Deletion Mode

Scripts can be deleted through a corresponding action in the Script Overview . The desired behavior for cases where a script 10

is applied as model listener or scheduled depends on the concrete application scenario of NSC. There might be scenarios 11 12

where scripts should be deleted including all associated schedules and registered interceptions. Other scenarios might re-quire that only unused scripts can be deleted. The configuration option script.delete.mode was added in order to support both types of scenarios. The following two values are supported for the property.

− CASCADE – The deletion of a script automatically leads to the deletion of all associated schedules and interception registrations. This implies that the permission to delete a script implies the permission to delete all associated schedules and interception registrations.

− UNSCHEDULED – Only unused scripts can be deleted successfully. If a user tries to delete a script which is sched-uled or registered for lifecycle interception, the script is not deleted and corresponding error messages are dis-played.

The default value of the property is UNSCHEDULED.

2.1.1.4. Schedule Execution Mode

NSC supports the scheduling of script executions12. In this context, scheduled executions of scripts might overlap. Through the property schedule.execution.mode it can be defined how NSC should behave for such cases. The following two values are supported.

− SEQUENTIAL – There can be only one scheduled script execution on each server node of your Liferay installation at any time. Thus, scheduled script executions are serialized on server node level.

− PARALLEL – NSC does not take care of serialization of scheduled script executions.

Besides the storage of group relations through identifiers, this property has major impact on other aspects of NSC.

− Site Admin Permissions - Site Administrators will not automatically have the permissions to create or exe-cute scripts if the property is set to COMPANY. This might be worth considering with respect to security aspects.

− Permission Assignment - Site- and organization roles as well as teams are not supported if the property is set to COMPANY. Therefore, the corresponding roles are not provided in permissions dialogs.

Scope group9

See section 3.1 Overview for further details.10

See chapter 4 Lifecycle Interception for further details.11

See chapter 5 Scheduling for further details.12


!

The default value of this property is SEQUENTIAL.

2.1.1.5. Output Processors

NSC supports the processing of script outputs through so called Output Processors. These are addressed in the dedicated chapter 6 Output Processing of this manual. The set selectable processors in the NSC user interface (UI) can be controlled through the property output.processors. It contains a comma-separated list of processor names. Supported names are

− Console – Activation of the Console output processor

− Log – Activation of the Log output processor

− JournalArticle – Activation of the Web Content output processor

− DocumentLibrary – Activation of the Document output processor

− Email – Activation of the Email output processor

− NoProcessing – Activation of the None output processor

Output processors can be deactivated by removing them from the list of provided processors.

!

The default value of this property is Console,Log,DocumentLibrary,Email,JournalArticle,NoProcessing.

!

2.1.2. portal-ext.properties

Further aspects of NSC can be influenced through portal properties. Each of the following subssections addresses one partic-ular property.

The background of this property is that there might be scenarios where a high number of script schedules exists for a given time span. In combination with long execution times, this might lead to situations where a high load is created through parallel script execution. Such scenarios can be avoided through setting this property to SEQUENTIAL as NSC will automatically serialize script execution in the context of schedules.

The property should be set to PARALLEL if the time of schedule execution is important as execution might be delayed

The removal of a provided output processor does not affect already stored schedule- and lifecycle interception con-figurations.

It might, e.g., be meaningful to set the property to Log only if outputs of schedules and lifecycle interceptions should always be written to log. Another example would be to remove the NoProcessing from the list in case discarding script outputs should be avoided.


2.1.2.1. Model Listener Manager

NSC registers as model listener in order to be able to execute scripts in response to model listener events. NSC comes with two strategies for event registration. The strategy to apply can be defined through the property application.startup.events. Supported values are

− com.prodyna.scriptcenter.portlet.intercept.management.

ClusteredLifecycleInterceptionManager – This strategy registers for all considered model classes. On event 13

occurrence it is identified if a script is registered for interception. This strategy must be applied in cluster environ-ments.

− com.prodyna.scriptcenter.portlet.intercept.management.

SingleInstanceLifecycleInterceptionManager13 – This strategy registers for lifecycle events on demand and deregisters again if applicable. This value should be applied in single instance, non-clustered environments only.

!

The default value of this property is

com.prodyna.scriptcenter.portlet.intercept management.ClusteredLifecycleInterceptionManager13.

2.1.2.2. Supported Model Classes

NSC can be configured to support certain service layer entities only through the property com.prodyna.scriptcenter.intercep-tion.classes.to.support. A comma-separated list of fully qualified class names to be supported can be set as value. On setting the value of this property to *, NSC will support all entities it can identify. The default value of this property is *.

2.2. Installation Procedure The installation of NABUCCO Script Center can be performed by simply copying the lpkg- or war file of the release into the 14

deploy folder of the Liferay-installation. NSC needs to be deployed into all installations of Liferay in a clustered environment.

2.3. Upgrade from Version 1.0.0 Version 1.0.0 is based on database tables which names are not compatible with certain database management systems (DBMS). A change of table names from version 1.0.0 to version 1.0.1 of NSC became necessary in order to support all consid-ered DBMSs. The upgrade process for existing installations of NSC based on version 1.0.0 addresses these table name changes. It creates the new tables and transfers all existing data like scripts and schedules into the new table structure. Corresponding messages are logged during the upgrade process. NSC does not delete any data or tables. Thus, the data stored by NSC version 1.0.0 remains stored in the database, but is not used anymore. Unused tables have the name prefix nabucco_script_center_ while new tables have the prefix nsc_. Unused tables might be deleted manually if it is verified that

The second strategy can be applied in non-clustered environments only. Otherwise, lifecycle events will be missed!

An advantage of the second strategy is that it is capable to intercept events of non-core model elements, i.e., service layer model entities of custom services.

The second strategy should be considered of being experimental!

No line break in property value.13

NSC is distributed as lpkg file in Liferay Marketplace and as war file on its homepage.14


https://www.liferay.com/marketplace/-/mp/application/55972350


all data has been transferred correctly during the upgrade process. It is strongly recommended to at least create a backup before deletion.

!

2.4. First Step After successful installation of NABUCCO Script Center, the portlet is available in the Applications menu at the category Tools as shown in the following screenshot.

!

Figure 1 – NABUCCO Script Center in Tools category of Applications

The functionality of NSC is accessible through the portlet NABUCCO Script Center. It can be deployed into pages as any other portlet through simple drag and drop.

The following screenshot shows the initial view of NSC after deployment into a page.

It is strongly recommended to create a backup of table contents before the deletion of deprecated tables! Furthermore, data transfer performed during the upgrade process from version 1.0.0 to version 1.0.1 should be verified after installation.


!

Figure 2 – Initial NSC view

NSC requires all of its users to agree with the terms of use. This can be done through checking the checkbox I agree with the terms of use at the bottom of the view and afterwards clicking the proceed button below. Agreement with the terms of use is required once by each user meaning that it is not necessary to re-agree for each portlet which might be deployed on another page.

After agreement with the terms of use, the user is forwarded to the Overview view of NSC. This is shown in the following screenshot.

!

Figure 3 – Initial Overview

Content and functionalities provided in this view are discussed in section 3.1 Overview of chapter 3 Script Management.


3. Script Management The central entities handled by NSC are scripts. This chapter provides an insight into all aspects of NSC being related to script management. The initial view of NSC provides an overview of scripts, schedules, and interceptions. It is presented in section 3.1 Overview. CRUD operations on scripts are discussed in the following four sections 3.2 Create, 3.3 Read, 3.4 Update, and 15

3.5 Delete. Afterwards, section 3.6 Copy shortly describes how to create a copy of an existing script. Finally, section 3.7 Im-port shows how to obtain and import scripts from the NSC homepage.

3.1. Overview The main view of the Script Center portlet provides a starting point for inspection and actions. The following image shows an exemplary main view of the portlet.

!

Figure 4 – Script Center Overview

The view mainly consists of three parts which are in particular the Breadcrumb Navigation, buttons for Script-Independent Actions, and the Summary Tabs. These three parts are presented in the following subsections.

3.1.1. Breadcrumb Navigation

Since version 1.1.0

The so-called Breadcrumb Navigation is provided at the top of each regular view of NSC. The following image shows an ex-emplary breadcrumb of a concrete schedule.

!

Figure 5 – Breadcrumb Navigation

Create Read Update Delete15


This navigation allows quick navigation between views of NSC. A concrete breadcrumb may contain up to four major parts (cf. Figure 5). These are in particular

• Overview – This link is provided as first element of each breadcrumb navigation. It refers to the Overview view of NSC as discussed in section 3.1.

• Script – This link is provided if the current view belongs to a concrete script. The script title is provided as label of this breadcrumb element. The associated hyperlink refers to the details view of a script which is described in sec-tion 3.3.

• Topic Overview – The third part of a concrete breadcrumb is provided if the current view belongs to the topic of a script. Supported topics are Interceptions and Schedules. The Interceptions hyperlink refers to the overview of life-cycle interceptions of a concrete script (see section 4.1 for further details). The Schedules hyperlink refers to the overview of schedules of a concrete script (see section 5.1 for further details).

• Topic Instance – This part of a breadcrumb is provided if the current view belongs to a concrete instance in the context of a topic, i.e. a concrete lifecycle interception (see section 4.3) or schedule (see section 5.3).

For the Script- and the Topic Instance parts of a breadcrumb, a wrench icon (! ) is additionally provided as part of a bread-crumb. This icon provides a hyperlink to the corresponding edit view of the breadcrumb element, i.e. the edit view of a script (see section 3.2), a lifecycle interception (see section 4.2), or a schedule (see section 5.2). The wrench icon is only provided if the current user has the required permissions to access the corresponding view in the particular context.

The current view is highlighted in grey within the breadcrumb by default.

!

Figure 6 – Breadcrumb Navigation II

Referring to the concrete breadcrumb shown in Figure 6, the current view is the detailed view of a script as it is highlighted in grey. The Overview hyperlink allows navigation to the Overview view of NSC. The wrench icon refers to the edit view of the script.

3.1.2. Script-independent Actions

A button row is provided as part of the main Overview view of NSC. It contains, depending on the permissions of the current user, at most the three following buttons.

!

Figure 7 - Script-independent Actions

− Add Script button – This button can be used to switch to the Script Editor in order to create a new script or for ad hoc execution of scripts without saving them (see section 3.2 Create for further details).

− Import Script button – This button can be used to switch to the Script Importer in order to import a script (see section 3.7 Import for further details).

− Permissions button – This button can be used to set model permissions independent from single scripts (see chapter 7 Permissions for further details).

3.1.3. Summary Tabs

Since version 1.1.0

In the lower part of the NSC Overview view different overviews are provided. These are in particular the Scripts, Schedules, and Interceptions. Each of them is provided through a separate tab as shown in the following image.


!

Figure 8 – Overview Tabs

Each of the above overviews is described in a separate subsection. On opening the Overview view of NSC, the Scripts tab is shown.

3.1.3.1. Scripts Overview

The Scripts Overview can be accessed through selection of the Scripts tab in the Overview view of NSC. The overview consists of a table with entries for each script being visible for the current user (VIEW permission). The collection of considered scripts might be limited to scripts being associated with the current site . The following image shows an exemplary Scripts 16

Overview.

!

Figure 9 – Scripts Overview tab content

The first column (Title) contains script names. The script abstracts are displayed in the second column (Abstract). The last column contains the actions menus (Actions). The available entries within each single menu depend on the permissions of the current user on the particular script. The following screenshot Figure 5 – Script Action Menu contains all possible menu entries for a script.

!

Figure 10 – Script Action Menu

The menu entries are in particular.

− View – This entry provides access to the View page of a script (see section 3.3 Read for further details).

This is given if the group mode is set to GROUP. Please refer to section 2.1.1.2 for further details.16


− Copy – A copy of the corresponding script can be created through this menu entry (see section 3.6 Copy for fur17 -ther details).

− Update - The Update view of a script can be reached through this menu entry (see section 3.2 Create for further details).

− Schedule - The scheduling of a script can be controlled through the Schedule view. The view can be reached through the Schedule menu entry (see chapter 5 Scheduling for further details).

− Permissions - The Permissions view of a script can be reached through clicking the Permissions menu entry. The Permissions view is based on the standard permissions-features of Liferay in particular on a permissions-URL (see chapter 7 Permissions for further details).

− Delete - The Delete menu entry allows the deletion of a script (see section 3.5 Delete for further details).

Instead of the actions menu, some scripts might only contain the entry License Information in the last row. Such entries are shown for imported scripts which contain license information. Licenses must be agreed with before any usage of such a script. A click on the License Information link opens the License view of a script. The following screenshot shows an example of the License view.

!

Figure 11 – Sample License view of a script

The upper part of the view is individual to each specific script. It contains the script title, its abstract and contact information of the script provider. Below that, copyright- and license information of the script are shown. The lower part of the view con-tains a checkbox with the label I agree with the script license, as well as two buttons proceed and cancel. The proceed button is deactivated on opening the License view of a script. On checking the checkbox, the proceed button is activated. Through a click on that button, users agree to the terms of use of the corresponding script and can use it.

since version 1.0.117


3.1.3.2. Schedules Overview

Since version 1.1.0

The Schedules Overview can be accessed through selection of the Schedules tab in the Overview view of NSC. The overview consists of a table with entries for upcoming schedule events being visible for the current user (VIEW permission). The col-lection of considered schedules might be limited to schedules being associated with the current site . The following image 18

shows an exemplary Schedules Overview.

!

Figure 12 – Schedules Overview

The first column (Title) contains script titles. Each title is deposited with a hyperlink referring to the Details view (section 3.3) of the corresponding script if the current user has view permissions for that script. The actual planned execution times are displayed in the second column (Planned Execution Time). The last column contains the execution interval of the particular schedule (Execution interval). Entries of the second and third column are deposited with a hyperlink referring to the Details view of the Schedule (section 5.3). Entries in the Schedules Overview view are sorted ascending by the second column.

3.1.3.3. Interceptions Overview

Since version 1.1.0

The Interceptions Overview can be accessed through selection of the Interceptions tab in the Overview view of NSC. The over-view consists of a table with entries for model classes for which at least one script is registered for lifecycle interception . 19

The collection of considered interceptions might be limited to schedules being associated with the current site . Figure 13 20

shows an exemplary Interceptions Overview.

The first column (Class Name) contains the fully qualified names of considered classes. The second column (Interception Registrations) contains information on lifecycle interception registrations for the particular class. Within each cell, all regis-tered interceptions are shown. Each registration is represented by the title of the corresponding script and the list of events the current registration relates to. Script titles are deposited with a hyperlink referring to the Details view (section 3.3) of the corresponding script if the current user has view permissions for that script. Event types are deposited with hyperlinks refer-


Permissions are considered, i.e., only lifecycle interceptions are taken into account for which the current user has view permissions.19



ring to the Details view (section 4.3) of the corresponding interception if the current user has view permissions for that inter-ception.

!

Figure 13 – Interceptions Overview

3.2. Create The Script Editor view can be reached through the Update or Copy menu entry of a script (section 3.1), through clicking the add script button in the overview (section 3.1) or through clicking the Update button in the Details view of a script (section 3.3). The following screenshot Figure 7 – Script Editor view shows an example of the Script Editor view. The view consists of four sections Title, Abstract, Description, Language, Source Code and Update Type (not shown) to enter the script core data. Below these sections three buttons Clear Output, Execute, and Save are provided. Finally, an Output section is provided.

− Title – The script title is used, amongst others, in the main view of NSC (see section 3.1).

− Abstract – The abstract is used as a kind of teaser text, amongst others, in the main view of NSC (see section 3.1). It is intended to give a short impression of what the script can be used for.

− Description – In comparison to the abstract, the description should provide more detailed information on how the script can be used. It is displayed in the View (see section 3.3), the Lifecycle Interception (see chapter 4) and the Script Scheduler view (see chapter 5) of a script. The description should cover all information a user needs to know in order to use the script properly.

!

Please note that a user does not necessarily have access to the script source code!

Users might, depending on their permissions on a script, be able to execute a script, register it for lifecycle intercep-tion, or schedule its execution, but not be allowed to see the source code of that script. Please refer to chapter 7 for further details regarding permissions.

Therefore, the description of a script should contain all information relevant for its execution, registra-


− Language – The script language is needed as base information in order to execute it with the corresponding script engine.

− Source Code – In this section, the original script can be entered or changed. The Source Code section of the view is realized based on the JavaScript editor CodeMirror. Please refer to the corresponding homepage for further de-tails . 21

− Update Type – This drop down menu is displayed only on script updates. It should be used to indicate which type of change was performed in comparison with the previous version of the script. Supported values are Major, Minor, Patch, and Build. The update type is only used for user information purposes. There is no further application of it in the context of NSC. There is especially no versioning supported.

!

Figure 14 – Script Editor view

The Execute button can be used to trigger script execution. Execution results are displayed in the Output section at the bot-tom of the view. An additional success message is displayed at the top of the view if script execution was successful. The Execute button is only displayed if the current user has the permission to execute scripts in general, or permissions to exe-cute and update the current script. Please refer to chapter 7 Permissions for further details.

Through clicking the Clear Output button the content of the Output section is removed.

http://codemirror.net21


http://codemirror.net

The Save button can be used to save the current script. The fields Title and Source Code are mandatory in order to success-fully save the script. The button is only provided if the current user has the permission to create a new script or to update the current script . 22

3.3. Read The following screenshot shows the Details view of a script.

!

Figure 15 – Details view of a script

The view consists of a header with the name of the script, a general information section, a source code section, and a button row.

The general information section covers the script abstract, its description, contact information, and version information. Con-tact information is only displayed if the script was imported.

The provision of the Save button depends on the context of opening the Script Editor view. If the editor is opened to create a new script or to copy 22

an existing one, the button is provided if the user has permissions to add a new script. The button is provided on updating an existing script if the user has update permissions for that script. Please refer to chapter 7 Permissions for further details regarding permissions.


The script section is only displayed if the current user has INSPECT permission on the script (see chapter 7 Permissions for further details). The section covers information on the script language and the original source code.

!

Below the information sections, buttons are provided to copy, update, execute, schedule, register for lifecycle interception, and to set permissions on the script. The provision of each of these buttons depends on the permissions of the current user on the script.

− Copy – Through the Copy button the Script Editor view can be reached (see section 3.6).

− Update – Through the Update button the Script Editor view can be reached (see section 3.2).

− Execute – Through the Execute button the current script can be executed. An output section is shown at the bottom of the view in the end of first execution. This section is shown in the following screenshot.

!

Figure 16 – Execute output section

The first line contains the general execution result (SUCCESS or FAILURE). Subsequent lines contain the original script output or, in case of FAILURE, more detailed information on the type of failure.

− Schedule – Through the Schedule button the Scheduler view can be reached (see chapter 5).

− Intercept – Through this button the Lifecycle Interception view of the script can be reached (see chapter 4).

− Set Permissions – The Set Permissions button opens the Permissions view of the script (see chapter 7).

3.4. Update Scripts can be manipulated through the Script Editor view. This view is discussed in section 3.2 Create in detail. The Script Editor view of a script can be reached either from the Overview of NSC through the action menus of scripts (see section 3.1 Overview), or from the Details view of a script (see section 3.3 Read).

3.5. Delete Scripts can be deleted through the Delete action menu entry of the Overview of NSC (see section 3.1 Overview).

The view permission on a script implies the permission to open the Details view of a script. In this context, it must be highlighted that a user does not necessarily have access to the script source code although he/she has permission to view the script!

Users might, depending on their permissions on a script, be able to execute a script, register it for lifecycle intercep-tion, or schedule its execution, but not be allowed to see the source code of that script. Please refer to chapter 7 for


!

3.6. Copy Since version 1.0.1

Scripts can be copied through the Copy action menu entry of the Overview of NSC (see section 3.1 Overview). Scripts can be copied if the current user has at least permissions to VIEW and INSPECT the original script, as well as to ADD a new script (see chapter 7 Permissions for further details on permissions).

On initiation of the Copy action, the Script Editor view (see section 3.2) is opened. All information fields except Update Type are filled with the corresponding values of the original script. In the following, the Script Editor view behaves the same as if a new script is created. The copy is not saved until the corresponding button is clicked in the Script Editor view.

!

3.7. Import The Import view can be reached through the Import Script button in the NSC Overview (see section 3.1). It consists of a file upload input field Script File and an Import Script button as shown in the following screenshot.

!

Figure 17 – Import view

Scripts to import are provided on the NABUCCO Script center homepage at https://www.prodyna.com/scriptcenter. They are provided through nsa files and can be downloaded and imported directly. 23

After selection of an nsa file and clicking the Import Script button, the script is imported automatically. Afterwards, NSC switches to the Overview and displays a success message. The new script is sorted into the table of available scripts.

Please consider the Script Deletion Mode regarding the deletion of scheduled scripts or scripts registered for life-cycle interception. The Script Deletion Mode is discussed in section 2.1.1.3 Script Deletion Mode.

The creation of a script copy only considers the script core information. Schedules and lifecycle interception registra-tions of the original script are not copied.

NABUCCO Script Center Archive23



4. Lifecycle Interception Scripts can be applied as model listeners. For further details on model listeners, please refer to the corresponding docu-mentation at Liferay.

This chapter discusses the user interface of NSC to manage (section 4.1), create (section 4.2), view (section 4.3), update (section 4.4), and delete (section 4.5) registrations for lifecycle interceptions. Additionally, section 4.6 Variables points out variables which are available on execution of scripts in the context of lifecycle interceptions.

4.1. Overview The Lifecycle Interception Overview view of a script can be reached through the Intercept menu entry of a script in the main view of NSC (see section 3.1) or through clicking the Intercept button in the Details view of a script (see section 3.3). The following screenshot shows an example of the Lifecycle Interception Overview.

!

Figure 18 – Lifecycle Interception Overview

In the header, the script name is shown. Below that the script abstract and -description are displayed. Through the Add Inter-ception button below the description a new lifecycle interception can be created. The button is provided only if the current user has sufficient permissions (see chapter 7 Permissions for further details). A click on the button opens the Interception Editor (see section 4.2 Create for further details).

At the bottom of the view, an overview of all active lifecycle interceptions of the current script is displayed. Each entry is characterized by a Plan and an Output mode. The plan covers information on the target model element and the lifecycle events to intercept. The output mode provides information on the processing of interception outputs. Finally, each entry pro-vides an Actions menu. The set of provided actions depends on the permissions of the current user (see chapter 7 Permis-sions for further details). The following screenshot contains all possible menu entries for a lifecycle interception.


https://dev.liferay.com/develop/tutorials/-/knowledge_base/6-2/creating-model-listeners

!

Figure 19 – Lifecycle Interception action menu

The menu entries are in particular.

− View -This entry provides access to the Lifecycle Interception Details of an interception (see section 4.3).

− Edit - This entry provides access to the Interception Editor of a lifecycle interception (see section 4.2).

− Permissions - This entry opens the permissions view of the interception (see chapter 7 Permissions for further details).

− Delete - This entry can be used to delete the interception (see section 4.5).

4.2. Create The Interception Editor view can be used to create or update a lifecycle interception. The view consists of the two sections Lifecycle Events and Output Configuration to enter the interception configuration data.

!

Figure 20 – Interception Configuration


Within the Lifecycle Events section the target model entity of interception can be selected from a drop down list. Below that list, the events of interest can be selected. These events correspond to the methods provided by the ModelListener interface (see documentation at Liferay).

Please refer to chapter 6 Output Processing for further details regarding output processing.

The Save button below the two sections can be used to save the interception.

4.3. Read The Details view is provided if the current user has VIEW permission (see chapter 7 Permissions for further details) on the corresponding lifecycle interception. The view itself consists of the full name of the interception's Author, the Interception Target provided by the interface name of the target entity, a list of Lifecycle Events to intercept, and the Output mode (see chapter 6 Output Processing for further details).

!

Figure 21 – Lifecycle Interception Details view

4.4. Update Lifecycle interceptions can be manipulated through the Interception Editor view. This view is discussed in section 4.2 Create. The Interception Editor view of a lifecycle interception can be reached from the Lifecycle Interception Overview view through the action menus of lifecycle interceptions (see section 4.1).

4.5. Delete Lifecycle interceptions can be deleted from within the Lifecycle Interception Overview view through the Delete action menu entries of lifecycle interceptions (see section 4.1).

4.6. Variables Scripts applied on lifecycle events can make use of variables which are made available by NSC. Basically, these variables correspond with the parameters of the corresponding methods of com.liferay.portal.model.ModelListener 24

Additionally, the type of event is also provided through a variable as scripts can be registered for multiple event types.

The following variables are available when a script is executed in the context of an entity event.

− eventType – Type of event, possible values are

− onBeforeCreate and onAfterCreate for creation events

− onBeforeUpdate and onAfterUpdate for creation events

Please refer to the documentation at Liferay for further details.24




− onBeforeRemove and onAfterRemove for creation events

The values are derived from the corresponding method names of com.liferay.portal.model.ModelListener

− model – Reference to affected entity

− className – Class (interface) name of affected entity

The following variables are available when a script is executed in the context of an association event.

− eventType – Type of event, possible values are

− onBeforeAddAssociation and onAfterAddAssociation for creation events

− onBeforeRemoveAssociation and onAfterRemoveAssociation for removal events

The values are derived from the corresponding method names of com.liferay.portal.model.ModelListener

− className – Class name of affected entity

− classPK – Primary key of affected entity

− associationClassName – Class name of associated entity

− associationClassPK – Primary key of associated entity


5. Scheduling Scripts can be applied to be executed at a specific time in the future or at regular intervals starting at a certain point in time.

This chapter discusses the user interface of NSC to manage (section 5.1), create (section 5.2), view (section 5.3), update (section 5.4), and delete (section 5.5) schedules of scripts.

5.1. Overview The Schedule Overview view of a script can be reached through the Schedule menu entry of a script in the main view of NSC (see section 3.1) or through clicking the Schedule button in the Details view of a script (see section 3.3). The following screenshot shows an example of the Schedule Overview.

!

Figure 22 – Schedule Overview

In the header, the script name is shown. Below that, the script abstract and -description are displayed. Through the Add Schedule button below the description a new schedule can be created. The button is provided only if the current user has sufficient permissions (see chapter 7). A click on the button opens the Schedule Editor (see section 5.2).

At the bottom of the view, an overview of all active schedules of the current script is displayed. Each entry is characterized by a Plan and an Output mode. The plan covers information on the date of first execution as defined on last storage of the schedule and the repeat interval. The output mode provides information on the processing of schedule execution outputs (see chapter 6). Finally, each entry provides an Actions menu. The set of provided actions depends on the permissions of the current user (see chapter 7). The following menu contains all possible menu entries for a schedule.


!

Figure 23 – Schedule action menu

− View -This menu entry provides access to the Schedule Details view of a schedule (see section 5.3). The entry is provided if the current user has VIEW permission on the corresponding schedule (see chapter 7).

− Edit - This menu entry provides access to the Schedule Editor view of a schedule (see section 5.4). The entry is provided if the current user has UPDATE permission on the corresponding schedule (see chapter 7).

− Permissions - This entry opens the permissions view of the schedule. The entry is provided if the current user has PERMISSIONS permission on the corresponding schedule (see chapter 7).

− Delete - This entry can be used to delete the schedule (see section 5.5). The entry is provided if the current user has DELETE permission on the corresponding schedule (see chapter 7).

5.2. Create The Schedule Editor view can be used to create or update a schedule definition. The view consists of the two sections Interval Configuration and Output Configuration to enter the schedule configuration data as shown in the following screenshot.

!

Figure 24 – Schedule Editor view

Within the Interval Definition section a point in time (date and time) can be configured at which the corresponding script should be executed the next time. This time must be in the future. In case of configuration of an existing schedule this time will be the next execution time of the schedule. This does not need to be the same as the one provided on schedule creation or reconfiguration. Below the Next Execution, the Repeat Type drop down can be used to configure if the schedule should be


executed Once or repeatedly (Every). A second drop down Interval is shown if every is selected at Repeat. Interval provides the options Hour, Day, Week, Month, and Year to configure the repeat interval.

! Please refer to chapter 6 Output Processing for further details regarding output processing.

Below these sections the Save button is provided to save the schedule.

5.3. Read The Schedule Details view consists of the full name of the schedule's Author, the Plan string, the time of Next Execution and the Output mode. Below this schedule core information the Execution History is displayed through a table. Each entry con-sists of a Start Date (the time when execution started) and an End Date (the time when execution ended). Additional informa-tion is provided in the last column of each entry. This might be a success-message or more or less detailed failure informa-tion, depending on the type of failure. If the execution is ongoing, the last two columns are left empty.

!

Figure 25 – Schedule Details view

5.4. Update Schedules can be manipulated through the Schedule Editor view. This view is discussed in section 5.2 Create. The Schedule Editor view of a schedule can be reached from the Schedule Overview view through the action menus of schedules (see sec-tion 5.1).

The schedule is automatically deleted after execution if Once is selected at Interval.


5.5. Delete Schedules can be deleted from within the Schedule Overview view through the Delete action menu entries of schedules (see section 5.1).

6. Output Processing Scripts might produce information which might be of further use when the execution finished. Examples of such information might be statistics or reports about script execution. In other case, the information a script produces might be the original reason for script execution. NSC facilitates the processing of script outputs through a two-step-proceeding. In a first step, script authors can write the relevant output of a script to a variable out as shown in the following Groovy snippet.

!

After script execution in the context of a schedule, the output provided through out can be further processed by NSC. For these purposes, NSC provides different types of output processor implementations. In the context of lifecycle interception- (section 4.2) and schedule edit views (section 5.2), the Output Configuration section addresses the configuration of output processing through NSC. The following screenshot shows the initial view on that section.

!

Figure 26 – Output Configuration section

The Processor drop down allows to select an output processor for the current configuration entity . The following types of 25

output processors are supported.

− Console - Output will be written to System.out (see section 6.1).

− Log - Output will be written to log(file) (see section 6.2).

− Document Library - Output will be written to a document in document library of the portal (see section 6.3).

− Email - Output will be sent through email (see section 6.4).

− Web Content - Output will be written into a web content (see section 6.5).

out.println "This is an exemplary script output."

Schedule or lifecycle interception.25


− No Output Processing - Output will not be written anywhere (see section 6.6).

An individual configuration section for each of the above processors is displayed if the corresponding option is selected. Each of those is described in a separate section of this chapter.

6.1. Console The Console processor writes execution output to System.out. The following screenshot shows the configuration section for the Console output processor.

!

Figure 27 – Console Output Configuration

No further configuration is needed for the Console processor. Therefore, its configuration section is empty.

On lifecycle interception- or schedule execution the script output will be written to System.out. Each line of script output is written into a separate line (System.out.println).

6.2. Log

The Log processor writes execution outputs to log. It supports the definition of a Log Level at which script output is written to the log. The following image shows the provided configuration option.

!

Figure 28 – Log Output Configuration

Lifecycle interception- or schedule execution output will be written to log with the defined Log Level. Each line of the output is put into a separate log message.

6.3. Document The Document processor writes script outputs into a document of portal document library. The configuration section of the Document output processor requires the specification of three aspects: Document Title, Storage Location, and Proceeding.

− Document Title – A valid file name must be entered into this text field. The value is used as title and file name of the document into which the script execution output is written. The field is mandatory, i.e., it must not be left emp-ty.

− Storage Location – A storage location within a document library must be selected within this part of the Docu-ment Library configuration section. For this purpose, a tree structure is provided. Site names are provided as top-


level tree elements. In the screenshot below, the site Guest is available. Additionally, the global scope is also 26

available (Global). The set of provided sites depends on site memberships of the current user, i.e., the user will only see site of which he/she is member of. Below the site elements, the corresponding document library folder struc-ture is provided. Only those folders are provided for which the current user has VIEW permission. The user must select a tree element for which he/she has ADD_DOCUMENT permission in order to be able to successfully save the schedule. A corresponding error message is displayed if the user has insufficient permissions to create a document in the selected storage location. The field is mandatory, i.e., a storage location must be selected.

− Proceeding – There are cases conceivable where a document with the Document Title already exists in the Stor-age Location. The document might, e.g., already exists, because it was created as part of another script execution result processing or by a user directly. For those cases, it can be defined how the Document Library processor should behave. The following options are supported.

− Add completely new document with time stamp suffix in title – The existing document is left un-touched. A new document with the File Name extended with a time stamp suffix is created. This option is recommended, e.g., if a folder is used to store histories of schedule execution outputs, and each output should be available as separate document.

− Add new version of existing document – The existing document is used as target of schedule output. The schedule output is written into a new version of that document. This option is recommended, e.g., if all outputs of subsequent schedule executions should be collected in a single document and should be sepa-rated through the version history.

− Replace content of current document version – The existing document is used as target of schedule output. The schedule output is written into the current content of the document replacing the original one. This option is recommended, e.g., if only the latest output of subsequent schedule executions is relevant.

− Do not write results of script execution – The existing document is left untouched. The schedule exe-cution output is discarded.

In summary, the Document Library processor takes the output of lifecycle interception- or schedule execution and stores it according to Proceeding for existing documents into a document with the title File Name at the Storage Location.

The corresponding configuration view is shown in the screenshot below.

The default site of the portal.26


!

Figure 29 - Document Output Configuration

6.4. Email The Email processor composes an email body out of script outputs and sends it to an email address. The configuration sec-tion of the Email processor requires the specification of three aspects: From, To, and Email Subject. The corresponding con-figuration view is shown in the following screenshot.

!

Figure 30 – Email Output Configuration

− From (Email Address) - A valid email address must be entered into this text field. The value is used as return address of emails sent by the Email processor. The


− From is mandatory, i.e., a valid email address must be provided. To (Email Address) - A valid email address must be entered into this text field. The value is used as receiver address of emails sent by the Email processor. The field is mandatory, i.e., a valid email address must be provided.

− Email Subject - An email subject must be entered into this text field. The value is used as subject of emails sent by the Email processor. The field is mandatory, i.e., the field must not be left empty.

The Email processor takes the output of schedule execution and sends it as body of an email to the email address specified at To providing From as return address and using Email Subject as subject of that email.

6.5. Web Content The Journal Article processor writes execution outputs into a web content. The configuration section of Journal Article pro-cessor requires the specification of three aspects: Web Content Title, Site, and Proceeding. The corresponding configuration view is shown in the screenshot below.

!

Figure 31 - Web Content Output Configuration

− Web Content Title – A valid journal article title must be entered into this text field. The value is used as title of the journal article into which the output is written. The field is mandatory, i.e., it must not be left empty.

− Site – A site must be selected at this drop down menu into which the journal article should be written. The set of provided sites depends on site memberships of the current user, i.e., the user will only see sites of which he/she is member of. The field is mandatory, i.e., a target site must be selected.

− Proceeding – A new journal article with the Web Content Title as title is created in the Site on first script execu-tion. For subsequent executions it can be defined how the Journal Article processor should behave. The following options are supported:

− Add completely new web content with same title – The existing journal article is left untouched. A new journal article with the Web Content Title is created. This option is recommended, e.g., if multiple journal articles with the same title are considered valid and script execution outputs should be stored in separate journal articles.


− Add completely new web content with time stamp suffix in title – The existing journal article is left untouched. A new journal article with the Web Content Title extended with a time stamp suffix is created. This option is recommended, e.g., if execution outputs should be stored in separate journal articles with separate but similar titles.

− Add new version of existing web content - The existing journal article is used as target of execution outputs. The output is written into a new version of that journal article. This option is recommended, e.g., if all outputs of subsequent executions should be collected in a single journal article and should be separat-ed through a version history.

− Replace content of current web content version - The existing journal article is used as target of script execution output. The output is written into the current content of the journal article replacing the original one. This option is recommended, e.g., if only the latest output of subsequent executions is con-sidered relevant.

− Do not write results of script execution - The existing journal article is left untouched. The schedule execution output is discarded.

The Journal Article processor takes the output of script execution and stores it according to Proceeding on subsequent exe-cutions into a journal article with the title Web Content Title in the context of Site.

6.6. None The None processor discards script outputs. This option is recommended, e.g., if the corresponding script does not produce output, the output is processed directly inside the script, or the output of a script is considered of not being relevant.


7. Permissions NABUCCO Script Center relies on the Liferay permission system. In the following chapters Portlet Permissions and Service Layer Permissions are addressed separately in separate sections of this chapter.

7.1. Portlet Permissions On portlet level the permissions Add to Page, Configuration, View, Help, About, Preferences, and Permissions are supported. All of these permissions are standard permissions of Liferay. Therefore, they are not discussed any further.

!

Figure 32 – Portlet Permissioins

7.2. Service Layer Permissions NSC supports permissions on service layer by means of the entities script, lifecycle interception and schedules. In the follow-ing subsection 7.2.1, general permissions on package level are discussed. Package level means that those permissions do not relate to an existing entity instance. Afterwards, script permissions (section 7.2.2), lifecycle interception permissions (7.2.3), and schedule permissions (7.2.4) are presented in separate subsections.

7.2.1. Package Level Permissions

Package Level Permissions are service layer permissions which are not directly related to an existing model entity instance. NSC supports the following package level permissions.

!

Figure 33 – Package Level Permissions

− ADD_SCRIPT – This permission allows users to add a new script. This does not imply the execution of a script.

− EXECUTE_SCRIPT – This permission allows users to execute a script in general. This implies the execution of scripts through the script editor without saving them.

− PERMISSIONS - The permission to set the package level permissions discussed in this section.


!

7.2.2. Script Permissions

Script Permissions are service layer permissions which directly relate to a concrete script instance. NABUCCO Script Center supports the following script permissions.

!

Figure 34 – Script Permissions

− DELETE – This permission allows users to delete a concrete script instance. This permission implies the deletion of all associated schedules in case the Script Deletion Mode is set to CASCADE (see section 2.1.1.3 for further de-tails).

− EXECUTE – This permission allows users to execute a concrete script instance.

− INSPECT – This permission allows users to inspect the source code of a script. This permission is provided in ex-tension to the VIEW permission as it should be possible to provide scripts without the need to allow users to in-spect its sources. A use case could be to allow users to execute a script which contains confidential information like credentials . 27

− PERMISSIONS – This permission allows users to set the permissions of a script.

− SCHEDULE – This permission allows users to create a schedule for a script.

− INTERCEPT – This permission allows users to create a lifecycle interception based on a script.

− UPDATE – This permission allows users to update a script. This permission does not directly imply the execution of that script (EXECUTE permission above). Nevertheless, the UPDATE permission on a script which is applied as model listener or scheduled job indirectly implies the EXECUTE permission as that script will most probably be automatically executed at some time in the future.

− VIEW – This permission allows users view a script. This permission does not imply access to the script source code (see INSPECT permission above).

There is no package level permission provided to create a lifecycle interception or a schedule as those permissions are bound to script instances (see section 7.2.2 for further details).

I'm not willing to discuss if it is a good idea to integrate credentials into script code. It is just an example.27


7.2.3. Lifecycle Interception Permissions

Lifecycle Interception Permissions are service layer permissions which directly relate to a concrete lifecycle interception. NABUCCO Script Center supports the following lifecycle interception permissions.

!

Figure 35 – Lifecycle Interception Permissions

− DELETE – This permission allows users to delete a lifecycle interception.

− PERMISSIONS – This permission allows users to set the permissions of a lifecycle interception.

− UPDATE – This permission allows users to update a lifecycle interception.

− VIEW – This permission allows users view a lifecycle interception.

7.2.4. Schedule Permissions

Schedule Permissions are service layer permissions which directly relate to a concrete schedule. NABUCCO Script Center supports the following schedule permissions.

!

Figure 36 – Schedule Permissions

− DELETE – This permission allows users to delete a schedule.

− PERMISSIONS – This permission allows users to set the permissions of a schedule.

− UPDATE – This permission allows users to update a schedule.

− VIEW – This permission allows users view a schedule.


NABUCCO Script Center Manual 1.1 - PRODYNA

Documents

Transcript of NABUCCO Script Center Manual 1.1 - PRODYNA