TIBCO LiveView Web

User Authorization Guide Introduction 3

Usage Notes 3

Location and Usage of the lvweb-* Tools 3

LiveView Web Authorization System 5

Initial Setup Using Permissions 5

What is a Privileged User? 5

Example Scenario 5

Step 1: Admin Creates the LiveView Web Resources 6

Step 2: Getting the IDs of the Created Resources 6

Step 3: Grant Permissions for guest 6

Step 4: Grant Permissions for limited_user 6

Step 5: Grant Permissions for regular_user 7

Using Permissions to Emulate 1.0.x Users 7

lvweb-copy 9

Synopsis 9

Description 9

Options 9

Usage Note 9

Examples 9

lvweb-db 10

Synopsis 10

Description 10

Options 10

Examples 10

lvweb-delete 12

Synopsis 12

Description 12

Options 12

Examples 12

2

lvweb-list 13

Synopsis 13

Description 13

Options 13

Examples 13

lvweb-permissions 14

Synopsis 14

Description 14

Options 14

Usage Notes 16

Examples 17

lvweb-reset 18

Synopsis 18

Description 18

Options 18

Examples 18

Shared Options 19

Permission List Syntax 20

Permissions File Format 20

Permissions File Example Lines 21

Resource Filter Specifications 22

Resource Filter Syntax 22

Resource Filter Examples 22

3

Introduction This guide describes how to use the lvweb-* tools included with TIBCO LiveView™ Web releases. These tools are used to configure user permission settings for a TIBCO Live Datamart (LDM) project to which LiveVew Web will connect as a client. These tools are only needed when the LDM project is configured to use authorization. The sample shipped with LiveView Web has authorization enabled; most samples shipped with LDM itself have authorization disabled. In the no-authorization state, every LiveView Web user connects to an LDM server with the same effective permissions, which are the equivalent of superuser privileges. By enabling authentication and authorization, LiveView Web administrators can restrict or enable users by dashboard, page, card, or linkage with very fine-grained control.

Usage Notes Note: The LiveView Web tools described in this Guide work in conjunction with the authorization mechanism of LDM itself. You must configure authorization settings in two realms:

● In the LDM authorization realm, using settings made in the LDM project’s liveview.properties and liveview.auth.properties files, or in your site’s LDAP database configuration. Enable authentication and authorization for your LDM project as described on the LiveView Server System Configuration page of the LiveView Administration Guide.

● In the LiveView Web realm, using the tools described in this Guide. Note: The lvweb-* tools can only be used on an LDM project that is not currently running.

Location and Usage of the lvweb-* Tools The lvweb-* tools are installed in the bin folder of your LiveView Web installation, along with their implementing lvweb-tools.jar file. On Windows, use the Start > All Programs > TIBCO > LiveView Web 1.3 > Install Directory menu to open a Windows Explorer window directly to the LiveView Web installation directory. The lvweb-tools.jar file must be present in the folder from which the tools are executed. The tools require that the environment variable STREAMBASE_HOME is set, pointing to the top level of your StreamBase+LDM installation. On Windows, use a StreamBase Command Prompt, which automatically configures the environment for command-line use, including setting of STREAMBASE_HOME. On macOS, configure your login shell environment using sb-config –env command, as described as a post-installation step in the OS X installation page of the StreamBase Installation Guide.

4

There are in general two ways to run any of the lvweb-* tools:

1. The simplest way to run any of the lvweb-* tools is to specify the full or relative path to their installation directory with each tool invocation. For example, on macOS: /Users/user/Applications/TIBCO LiveView Web 1.3/bin/lvweb-list

Because this would mean a great deal of typing for each command, set up an environment variable that contains the path to the installation’s bin directory: On macOS: export LVWT=”/Users/user/TIBCO LiveView Web 1.3/bin”

cd <project-dir>

$LVWT/lvweb-list –p .

On Windows: set LVWT=”C:\Users\user\AppData\Local\TIBCO Software Inc\LiveView

Web 1.3\bin”

cd <project-dir>

%LVWT%\lvweb-list –p .

2. You can also run the lvweb-* tools from their installed bin directory. In this case, the long path to type is the path to your LDM project folder. You can, again, set up an environment variable containing the path to your project folder in the Studio workspace. Use quotes around the path when setting up your environment variable to escape any spaces. Let’s say you set up the variable PROJ. Thereafter, you can run the commands like these examples: On macOS: cd ”/Users/user/TIBCO LiveView Web 1.3/bin”

./lvweb-list -p "$PROJ" –c

On Windows: cd ”C:\Users\user\AppData\Local\TIBCO Software Inc\LiveView Web

1.3\bin”

lvweb-list -p "%PROJ%" –c

This Guide provides an overview discussion of the workflow and expected usage of the tools, then provides reference pages for each of the lvweb-* tools in alphabetical order.

5

LiveView Web Authorization System This section describes the workflow to grant users permission to use and edit LiveView Web resources.

Initial Setup Using Permissions This section describes the initial setup that must be completed to allow users to log in and use LiveView Web in any authentication-enabled project.

In LiveView Web, the admin user (or another user with privileged permissions, as described next) can create dashboards for other users. This style of setup allows giving an initial set of dashboards to LiveView Web users and also allows greater control over the ways users can interact with various levels of LiveView Web resources.

What is a Privileged User? A privileged user has all permissions (current and future) on all resource types (current and future). Semantically, it can be represented as a user who has permissions configured as ANY:ANY. LiveView Web exposes a property called

liveview.web.privileged.principals to enable configuration of a list of privileged users. The property takes a comma-separated list of user names to be given the ANY:ANY permission. By default, LiveView Web creates privileged permissions for the admin user, if that name is configured in the liveview.auth.properties file or LDAP database.

Example Scenario The following sections describe the steps to create a set of users for a LiveView Web system. These steps are to be run by a user named admin, who is established as a privileged superuser in the liveview.auth.properties file (for a non-LDAP project). The users to be created are the following:

• guest, who has read-only access to the dashboard created by admin. • limited_user, who can modify the dashboard created by admin but cannot

add his or her own resources to it . • regular_user, who can modify the dashboard created by admin as well as

create his or her own resources. These steps assume you are configuring a new Live Datamart project that has been configured for access from LiveView Web users by copying the LiveView Web lvweb.war file to the project’s lv-user-webapps folder. You can also run the sample that ships with LiveView Web for reference. Most of the following steps are already accomplished in the sample as shipped.

6

Step 1: Admin Creates the LiveView Web Resources Once the users have been added to liveview.auth.properties file, run the project as a LiveView project.

1. Connect to the server with LiveView Web, and log in as admin, password admin. Create a page named LVSessions, add two cards to the page and configure those cards as follows. One card shows the current set of LiveView sessions as a grid, and the second card shows the list of queries in each session. The second card is linked to the first card so that when you select an LVSessions table row, you will see the queries running in the selected session.

2. Shut down the LDM server, then perform the next steps.

Step 2: Getting the IDs of the Created Resources 1. LiveView Web tools work with the IDs of the resources. Use the lvweb-list

command to determine the IDs of the dashboard, page, and two cards created so far.

2. Run the command: lvweb-list –p /path/to/project-folder –c

3. This command returns a number of lines like the following. Only the first few words of each line are shown here to save space: Using /path/to/project-folder as project output folder with … Dashboard [id=1, name=, modifiedDate=date author=admin … Page [id=1, name=LVSessions, modifiedDate=date author=admin … Card [id=1, name=LVSessions … Card [id=2, name=LVSessionQueries … Linkage [id=1, name=null, …, sourceCardId=1, targetCardId=2 …

Step 3: Grant Permissions for guest 1. Run the following command to grant read-only permission to all children

and grandchildren of dashboard ID 1. lvweb-permissions –p /path/to/project –g read –r dashboard/1/**/* –u guest

2. The command returns output that includes a line like the following. Created 5 and updated 0 permissions for guest.

Step 4: Grant Permissions for limited_user 1. Run the following commands to grant read and personalize permission to

page 1 and its cards and linkages.

lvweb-permissions –p /path/to/project –g read,personalize –r dashboard/1/**/* –u limited_user

7

Step 5: Grant Permissions for regular_user 1. Run the following commands to grant CREATE permission for

dashboards, pages, cards, and linkages, and to grant read and personalize permission to page 1 and its cards and linkages:

lvweb-permissions –p /path/to/project –g create –r dashboard/-1 –u regular_user lvweb-permissions –p /path/to/project –g create –r page/-1 –u regular_user lvweb-permissions –p /path/to/project –g create –r card/-1 –u regular_user lvweb-permissions –p /path/to/project –g create –r linkage/-1 –u regular_user lvweb-permissions –p /path/to/project –g read,personalize –r page/1/* –u regular_user

Using Permissions to Emulate 1.0.x Users In LiveView Web 1.0.x, users were added to the system by adding entries to the liveview.auth.properties file. Once the users logged in, they would be given their own personal dashboard. To achieve similar behavior (starting with LVWeb 1.1.x), the same liveview.auth.properties file needs to be modified to include create permissions for all dashboard resources. For example, in the sample shipped with LiveView Web, the liveview.auth.properties has create permissions for the LVUser role: role.LVUser = connect, table:list, table:manage, table:*:ItemsSales,

table:query,

alert:list, alert:set:ItemsSales, alert:delete,

alertaction:publish:ItemsSales,

alertaction:email:ItemsSales, alertaction:sendtuple:ItemsSales,

tuple:info:ItemsSales.DataIn, tuple:send:ItemsSales.DataIn,

workspace:get:Auth Sample, dashboard:create, page:create, card:create,

linkage:create

The following table explains some of the permissions added:

Permission Explanation

dashboard:create Allows creating dashboards

page:create Allows creating pages

card:create Allows creating cards

linkage:create Allows creating linkages

8

Note: LiveView Web does not support migration of 1.0.x resources to 1.3.x format.

9

lvweb-copy

Synopsis lvweb-copy -p path-to-project [–t [h2|file]] –s srcuser –d destuser

Description Copies the permissions and resources created by and personalized by the source user to the destination user. The tool copies the resources by value (not by reference) so all the copied resources are owned by the destination user.

Options -s | --sourceUser srcuser Specifies the srcuser whose permission settings are to be copied. The srcuser must already exist in the project’s liveview.auth.properties file or in the configured LDAP database. Notice that the long name version of this option has an uppercase U, which must be typed as shown. -d | --destinationUser destuser Specifies the destuser whose permission settings are to be granted. Notice that the long name version of this option has an uppercase U, which must be typed as shown. If the destuser does not already exist in the project’s primary authorization realm (the project’s liveview.auth.properties file or in the configured LDAP database), the destuser is added to LiveView Web’s H2 permissions store, but destuser cannot log in and use LiveView Web resources until also added to the configured primary authorization realm. For –p and –t, see the Shared Options section below.

Usage Note ● Do not specify “admin” as the srcuser to copy from, even if your LDM

authorization scheme does not specify a user named “admin.” This username is a special case name reserved by default as the LDM superuser name. For this reason, copying permissions from this username is blocked.

Examples lvweb-copy –p /path/to/project –s earlyuser –d newuser

Copies the permission settings for all resources personalized by and created by earlyuser to newuser.

10

lvweb-db

Synopsis lvweb-db -p path-to-project [-e | -i] [-o] [–d path-to-backup-dir] [-f path-to-zip-file]

Description Supports import and export operations that allow you to backup and restore the contents of an H2 database that contains all LiveView Web authentication settings and resources. The storage format for the backed-up data is a zip file.

Options -d | --directory path-to-backup-dir Specifies the path to a directory that contains a default-named zip file to be imported into the H2 database, or that is to contain a zip file exported from the H2 database. If not specified, the current directory is used. Specify either –d or –f. If both are used, the -f option takes precedence. -f | --file filename.zip Specifies the path to a zip file to export into or to import from. If –f or --file is used, you must specify the filename.zip argument. If –f is omitted, the command uses lvw-db.zip. -e | --export Exports authentication settings and resources from the specified project’s H2 database to the default file name or to the file specified with –f. Writes the output file to the current directory, or to the path specified with –d. -i | --import Imports authentication settings and resources from the default zip file name, or from a file named with –f, into the specified project’s H2 database. Prompts for permission to override the H2 database unless –o is also specified. -o | --override Used only with –i import operations to pre-answer the prompt for permission to override the H2 database’s current settings. For –p, see the Shared Options section below.

Examples lvweb-db –p /path/to/project -e

Exports all H2 data in the specified project to a file named lvw-db.zip in the current directory.

11

lvweb-db –p /path/to/project –e –d C:\Bkp

Exports all H2 data in the specified project to a file named lvw-db.zip in C:\Bkp. lvweb-db –p /path/to/project –e –f C:\Bkp\lvweb_160901.zip

Exports all H2 data in the specified project to a file named lvweb_160901.zip in C:\Bkp. lvweb-db –p /path/to/project -i

Imports all backed-up data from a file named lvw-db.zip in the current directory to the specified project’s H2 database. Prompts for permission to overwrite. lvweb-db –p /path/to/project –i –d C:\Bkp

Imports all backed-up data from a file named lvw-db.zip in C:\Bkp to the specified project’s H2 database. Prompts for permission to overwrite. lvweb-db –p /path/to/project –i –f C:\Bkp\lvweb_160901.zip

Imports all backed-up data from a file named lvweb_160901.zip in C:\Bkp to the specified project’s H2 database. Prompts for permission to overwrite. lvweb-db –p /path/to/project –i -o

Imports all backed-up data from a file named lvw-db.zip in the current directory to the specified project’s H2 database, overwriting the existing H2 database.

12

lvweb-delete

Synopsis lvweb-delete -p path-to-project [–t [h2|file]] –u username

Description Deletes the specified username completely from LiveView Web storage. All of username’s created and personalized resources are deleted, and all permission settings associated with username are deleted. There is no recovery option for this command, so please back up your data with the lvweb-db command before running this command.

Options -u | --user username Specifies the username that is to be deleted. For –p and –t, see the Shared Options section below.

Examples lvweb-delete –p /path/to/project –u newuser

Deletes all permissions and resources created by or personalized by newuser from the specified project.

13

lvweb-list

Synopsis lvweb-list -p path-to-project [–t [h2|file]] [–r resource-filter] [-c]

Description Returns a list of the specified resources in the specified project, showing the ID number of each resource. You can use resource IDs when specifying permission settings with the lvweb-permissions command.

Options -r | --resource resource-filter Accepts one resource-filter, which follows the syntax described in Resource Filter Specifications. The default resource-filter is *, which specifies all resource types, if you do not include a –r option. -c | --showchildren Add the –c option to show the children of each specified resource type, indented under each resource instance. Dashboards show all of each dashboard’s pages, while pages show all of each page’s cards and linkages. For –p and –t, see the Shared Options section below.

Examples lvweb-list –p /path/to/project –r dashboard/* -c

Returns a list of all dashboards in the specified project, with each page of each dashboard indented under its parent dashboard. Each card and linkage of each page is further indented under its parent page. lvweb-list –p /path/to/project –r *

lvweb-list –p /path/to/project

Either command returns a list of all resources in the specified project. lvweb-list –p /path/to/project –r dashboard/*

Returns a list of all dashboards in the specified project. lvweb-list –p /path/to/project –r page/Price.* Returns a list of all pages in the specified project whose name starts with “Price”.

14

lvweb-permissions

Synopsis lvweb-permissions -p path-to-project [–t [h2|file]] –u username -g permission-list [-r resource-filter] lvweb-permissions -p path-to-project [–t [h2|file]] –u username -k permission-list [-r resource-filter] lvweb-permissions -p path-to-project [–t [h2|file]] –u username [-e -f filename] lvweb-permissions -p path-to-project [–t [h2|file]] –u username [-i -f filename] [-d] [-o]

Description In the first format, using the –g option, used to specify a list of permission settings to be applied to a resource filter specification for the specified username. In the second format, using the –k option, used to revoke a list of permission settings for a resource filter specification from the specified username. In the third format, using the –e option, used to export current permission settings for username to a permissions file. In the fourth format, using the –i option, used to import permission settings for username from a permissions file, optionally overwriting existing settings. At import time, you can also optionally update all dashboards owned or updatable by username to contain references to all pages accessible by username. The syntax for all permission-list arguments is described in Permission List Syntax. The syntax for all resource-filter arguments is described in Resource Filter Specifications. There is no recovery option for this command, so please back up your data with the lvweb-db command before running this command. In case of incorrectly granted or imported permissions, you can use the lvweb-delete command to remove all permissions for username, then re-import them, or re-grant them with another lvweb-permissions command.

Options -u | --user username Specifies the username whose permissions are to be modified. This parameter is always required. If the username does not already exist in the project’s primary authorization realm (the project’s liveview.auth.properties file or in the configured LDAP database), the username is added to LiveView Web’s H2 permissions store, but username cannot log in and use LiveView Web resources until also added to the configured primary authorization realm.

15

-g | --grant permission-list Grants username the permissions specified in permission-list to the resources specified with the –r option. The syntax of the permission-list argument is described in Permissions List Syntax below. -k | --revoke permission-list Revokes from username the permissions specified in permission-list to the resources specified with the –r option. The syntax of the permission-list argument is described in Permissions List Syntax below. -r | --resource resource-filter Accepts one resource-filter, which follows the syntax described in Resource Filter Specifications. The default resource-filter is *, which specifies all resource types, if you do not include a –r option. -e | --export Specifies an export operation for the specified username, extracting all current permission settings into the file specified with –f. -f | --file Specifies the path to a file to contain permission settings exported with –e, or the path to a file that contains permission settings to be applied to username with –i. This option is required when using either –e or –i. See Permissions File Format for details. -i | --import Specifies an import operation that reads the permission settings from the file specified with –f and applies them to username. When using –i, you can also specify the -o and -d options. -o | --override Used only with –i in LiveView Web 1.1.2 and later releases. Specifies overriding all existing permissions for an import operation. (The default mode for imports is to merge settings from the imported permissions file with any existing settings for username.) -d | --updatedashboards Use only with –i. Specifies updating all dashboards owned or updatable by username to contain references to all pages accessible by username. This option is ignored if importing a dashboard. -m | --mergeimport Deprecated option. Used only with –i and only in LiveView Web 1.1.1, this option

16

specified merging the settings imported from the permissions file with any existing settings for username for all resources. In LiveView Web 1.1.2 and later releases, the sense of merging is inverted. Thus, merging is the default mode for –i import operations, and you can specify –o to override all existing permissions during import. For –p and –t, see the Shared Options section below.

Usage Notes ● The –d option allows you to create a new dashboard for which the user has

all permissions. The newly created dashboard will contain all the pages accessible to the user.

● Generally, avoid giving update permissions for a dashboard. If the dashboard

is shared between multiple users, confusing configurations can arise, such as when UserA and UserB both can update dashboard 1. UserA adds a new page with ID 1, but only UserA can access page 1. Nevertheless, page 1 gets added to dashboard 1. Now when UserB accesses dashboard 1, he or she will get an unauthorized error when trying to modify page 1.

● You can import an existing dashboard with read permission to restrict the

user to only the pages currently present in the dashboard, or you can import an existing dashboard with read and personalize permissions to allow the user to personalize the dashboard.

● The import tool imports permissions in the order read from the permissions

file. If a resource is configured more than once in a permissions file, the last processed permission wins. For example, if you import a page and all its cards with read permission, and a later line in the file specifies one of the cards to have personalize permissions, then that card will have only personalize and not read permissions.

● Specify resource-level permissions after all resources with child and

grandchild syntax have been specified. For example, let's say you have a page with ID 1 that contains cards with ID=2 and ID=3. Your goal is to make the page and card 2 read-only, but to grant card 3 read and personalize permissions. You can use a permissions import file like the following:

# Import page 1 and all its cards with read access page/1/* = read

# Update card 3 to add personalize permission card/3 = read,personalize

17

Examples lvweb-permissions –p /path/to/project –g dashboard/1/**/*

-r read,personalize –u user1

Grant user1 read and personalize permission for all resources in the dashboard with ID 1.

lvweb-permissions –p /path/to/project –k page/3/*

-r personalize –u user1

Revoke personalize permission from user1 for the page with ID 3 and its cards and linkages.

lvweb-permissions -p /path/to/project -e -f user1.permissions

-u user1

Export all the permissions of user1 into a file named user1.permissions from the specified project. lvweb-permissions -p /path/to/project -i -f user1.permissions

-u user1 -d

Import all the permissions defined in a file named user1.permissions for user1 and optionally create a dashboard with the accessible pages in it for the specified project. lvweb-permissions -p /path/to/project -i -f user1.permissions

-u user1 -d -o

Import all the permissions defined in a file named user1.permissions for user1, overriding existing permissions, if any, with permissions from the file, and optionally create a dashboard with the accessible pages in it for the specified project.

18

lvweb-reset

Synopsis lvweb-reset -p path-to-project –u username [–t [h2|file]]

[-a]

Description Resets all resources personalized by username back to their state before any such personalization. By adding the optional –a argument, you can also remove all resources created by username. There is no recovery option for this command, so please back up your data with the lvweb-db command before running this command.

Options -u | --user username Specifies the username whose permissions are to be reset. -a | --all In addition to resetting all personalized resources, delete all resources created by username. For –p and –t, see the Shared Options section below.

Examples lvweb-reset –p /path/to/project –u newuser

Resets all resources personalized by newuser back to their initial state in the specified project. lvweb-reset –p /path/to/project –u newuser –a

Resets all resources personalized by newuser as above, and also deletes all resources created by newuser.

19

Shared Options The following options have the same meanings for all of the lvweb-* commands. -h | --help Shows usage text for this command. --version Returns the current LiveView Web version number. -p | --projectDir path-to-project Specifies the relative path from the location of this lvweb-* command, or the full, absolute path, to the Live Datamart project folder that contains the project that LiveView Web is to query. If the path to the project includes a space, use quotes around the path. Notice that the long version of this option has an uppercase D, which must be typed as shown.

Tip: In StreamBase Studio, use the StreamBase > Open Command Prompt Here command (Windows) or the StreamBase > Open Command Terminal Here command (macOS) to open a window whose current directory is the selected Studio project. Then capture the current directory into an environment variable that you can later use as an argument to the –p option. If the path to the project includes a space, use quotes around the environment variable invocation: -p "$PROJ" (for macOS) -p "%PROJ%" (for Windows)

-t | --pstoreType “h2” | “file” Specifies whether the project specified with –p stores its LiveView Web persistence data in an H2 database in the project folder, or in a debugging file format. Notice that the long name version of this option has an uppercase T, which must be typed as shown. The default and strongly recommended persistence type is h2. Do not use the –t file option except under the direction of TIBCO Support personnel. If so directed, specify using the debugging file format by placing the following line in the sbd.sbconf for your Live Datamart project: <sysproperty name="liveview.web.pstore.type" value="file"/>

20

Permission List Syntax The syntax of a permission-list argument in lvweb-* commands and in a permissions file is a comma-separated list of permissions keywords, with no spaces between keywords.. The following lines show examples of valid permission-list arguments:

read,personalize read,update,delete read,personalize,delete create any

The permission keywords you can grant to any LiveView Web resource are based on the resource type:

Resource Supported Permissions Keywords

dashboard [CREATE, READ, UPDATE, DELETE, PERSONALIZE] or ANY page [CREATE, READ, UPDATE, DELETE, PERSONALIZE] or ANY

card [CREATE, READ, UPDATE, DELETE, PERSONALIZE, EXPORT_DATA] or ANY

linkage [CREATE, READ, UPDATE, DELETE, PERSONALIZE] or ANY Permission keywords (case insensitive in use) have the following meanings:

● CREATE grants the ability to create this resource type. This has no meaning for existing resources with IDs, and is therefore best used with the -1 ResourceID.

● READ, UPDATE, and DELETE have the obvious meanings for the specified resource type. Be careful when granting UPDATE rights for the same resource to two or more users, because their changes to the resource can conflict.

● PERSONALIZE grants update rights to a private copy of the resource. Use PERSONALIZE instead of UPDATE for most resources.

● EXPORT_DATA only applies to the CARD resource type, and enables a drop-down menu item that allows a snapshot of the card’s current data to be exported. Exported data is saved to the local machine’s Downloads directory as CSV files for tabular data and PNG files for charts. File names are generated from the card name.

● ANY grants a combination of all allowed permissions for the specified resource type. ANY includes UPDATE instead of PERSONALIZE; thus do not grant ANY rights lightly. It is designed for administrator user names.

Permissions File Format Permissions files generated by the –e export option, or imported with the –i option,

21

follow the syntax of Java properties files: resource-filter=permission-list

Where:

● The syntax for a resource-filter is described in Resource Filter Specifications. ● The syntax for a permission-list is described in Permission List Syntax. ● Lines beginning with # are comment lines.

Permissions File Example Lines # Import dashboard ID 1 with read permission: dashboard/1=read # Import dashboard ID 2 and the pages it contains with read and # personalize permissions: dashboard/2/*=read,personalize # Import dashboard ID 3 and the pages it contains along with all the # cards and linkages in each page, all with read and personalize permissions: dashboard/3/**/*=read,personalize # Import page ID 1 with read permission: page/1=read # Import page ID 2 and its cards and the linkages it references with # read permission: page/2/*=read # Allow creation of dashboards: dashboard/-1=create # Allow creation of pages: page/-1=create # Allow creation of cards: card/-1=create # Allow creation of linkages: linkage/-1=create

22

Resource Filter Specifications This section explains the syntax of the resource-filter argument for the –r option used in the lvweb-list and lvweb-permissions commands, and also used in permissions files. Resources are the following LiveView Web objects:

dashboard, page, card, linkage These objects have the following parent-child relationships:

Resource Type Children Grandchildren

dashboard page card, linkage

page card, linkage --

Resource Filter Syntax The syntax for a resource-filter argument is: resourceType/resourceID/showChildren

Where: resourceType can be a single asterisk (*) or one of dashboard, page, card, or linkage. resourceID is optional. If used, it can be:

● A single asterisk to indicate all resourceIDs. ● A positive integer indicating the ID of a resource as maintained in a LiveView

Web project’s database, and as shown with the lvweb-list command. ● -1, used with CREATE permission to indicate a resourceType that does not yet

exist. ● A Java regular expression using the syntax of java.util.regex.Pattern that

resolves to a string that matches the name of one or more resources in the current project.

showChildren is optional and can be a single asterisk (*) to indicate immediate children only, or can be **/* to indicate all children and grandchildren.

Resource Filter Examples Filter Expression Meaning * All dashboard, page, card, and linkage resources.

*/* All dashboard, page, card, and linkage resources. */*/* All dashboard, page, card, and linkage resources with

23

immediate children.

*/*/**/* All dashboard, page, card, and linkage resources with immediate children and grandchildren.

dashboard/* All dashboards. dashboard/1 The dashboard with ID 1.

dashboard/1/* The dashboard with ID 1 and all pages of that dashboard. dashboard/*/**/* All dashboards with all pages under each dashboard and all

cards and linkages under each page. page/System Info/**/*

All pages whose name matches “System Info” with all cards and linkages under such pages.

page/System.*/**/* All pages whose name begins with “System” with all cards and linkages under such pages.

dashboard/-1 Used to grant or revoke dashboard CREATE permission for a user.

page/-1 Used to grant or revoke page CREATE permission for a user. card/-1 Used to grant or revoke card CREATE permission for a user.

linkage/-1 Used to grant or revoke linkage CREATE permission for a user. dashboard/-1/* Used to grant both dashboard and page CREATE permission.

dashboard/-1/**/* Used to grant permission to CREATE all resource types. Copyright © 2017 TIBCO Software Inc. All rights reserved.