SMTX Support SMTX Wiki

Views

Overview

With views pending and closed tickets can be displayed to users. Multiple views can be defined to show for example the pending and closed tickets in separate views. There is no limitation in the number of views that can be defined. Views are displayed in the Views panel of the Dashboard where the various sections can be expanded/collapsed. Typical examples of views are as follows.

- All My Open Actions : All Tickets where the User is an Actor in the currently open Step.

- All Pending Actions : All Open Tickets of the User.

- All Closed Tickets : All recently closed Tickets of the User.

- All My Open Actions in escalation : All Open Tickets of the User where the Actor has not yet processed the currently open Step.

- All My Favorites : All Favorite links that have been added in Persons&Accounts > Managing Persons > Favorites will appear on user`s Dashboard.

- All My Access Services : All Access Services of the User.

- All My Drafts : All Drafts of the User.

Views Admin Page

The Views main admin page displays a list of all current Views.

Each View has the following list of controls:

  • Edit : Change the details of the selected Topic

  • Delete : Delete the selected Topic.

    • ! Please ensure that the View is no longer live on the Dashboard before deleting it.

  • Create a new View. To import a view from another environment, use the add new view button and upload the view XML in the next screen.

General Settings

The General Settings section contains the following options:

  • XML File : Use the browse button to browse for a XML file that contains a view definition. This button will open the standard Browse window to locate the file, either on the PC or on the network. When the file is selected from the popup window, the full path will appear in the text box. Use theclip0053button to upload and use this XML file.

  • Download : Use theclip0054button to download the current view settings into an XML file. This XML file can be edited or used to import the view in another environment.

  • Live on application: When this box is checked, the Topic will be shown to the Users of SSP 7. If the checkbox 'Live on Application' is not checked, it will not be shown to any Role, regardless of the Role settings.

  • Open detail in new window : Select this option to open detail form in a new browser window.

  • Expand on dashboard: Show Result on Dashboard in an expandable format.

  • Always open on Dashboard: the view will always be expanded on the Dashboard

  • Hide when count is 0: the view will only appear if there are tickets to show in the view

  • Allow users to hide columns: when this option is selected, the users can hide/unhide any columns in the view

  • Disable fix for SQL parameter bug: only use it if certain of this option

  • The display width of the view can be set for normal view and for full screen in pixels.

  • Display type: depending on ticket status, the options are Completed, Denied, Drafts, Open, Starred and Todo

  • Details URL: Provide the details view from either defined Internal or external source. This contains the URL that will be used to go to the detail of 1 record inside the view. This URL can contain placeholders for data inside the record. The format of the placeholder is “$ColName$” (without quotes) where ColName is the name of the source column

  • Connection type:

    • Internal: running in the SSP database using SSP’s connectionstring

    • SQL Server: external SQL DB, for which a connection string needs to be provided

    • Oracle: external Oracle DB, for which a connection string needs to be provided

    • Datastore: Source is a datastore parameter, no query or connection string is required

    • Tickets: Tickets within the ssp system on which filters can be defined within the query box

  • Query: The query used to retrieve data from the connected database

    • Query: For internal, SQL and Oracle connections, the query must be entered. You can use placeholders in the query:

    • $orderby$ will be replaced by the generated order by clause

    • $account_id$

    • $person_id$

    • $person_firstname$

    • $person_lastname$

    • $person_email$

    • person_uid$

    • $language_id$ current selected language

    • $person_ExtraFieldName$ where “ExtraFieldName” is the name of the person custom field (SSP fieldname) as defined in Admin – Adapters – User Data

  • Current Icon: If an icon is uploaded before, it is shown here. This icon is used on the top left hand side of the Dashboard, next to the Welcome-text. Use the delete button ( delete ) to remove the existing thumbnail.

  • Upload New Icon: Use the browse button to browse for a new icon. This button will open the standard Browse window to locate the file, either on the PC or on the network, using mapped drives.

    • !Please ensure the new Icon has these measures: width: 58 - Height: 49. When the file is selected from the popup window, the full path will appear in the text box. Use the UPLOAD button to upload and use this new Icon. Browsing for the file will not succeed, it is required to click the UPLOAD button to transfer the file to the server and to be used on the Dashboard. Due to caching, it is possible that the new icon is not shown immediately.

  • Name English : Enter the Title for the Topic in all installed languages. This text appears on the Dashboard in the section header.

Type: Internal

For the Internal type of view no XML file needs to be edited or uploaded. Internal type views can query the SSP7 database and display the results in a view.

In order to make an internal type of view work, the following settings need to be made:

Connection Type: Internal

Query: The query that should run on the SSP7 database

Fields: On the Fields tab of the view settings, define the fields that are returned by the defined query and define how these fields are displayed in the view. Use the alias or column name in case no alias is used to identify field names.

Type: Datastore

For the datastore type of view no XML file needs to be edited or uploaded. Datastore type views can display the contents of a datastore parameter within a view on the dashboard.

In order to make a datastore type of views work, the following settings need to be made:

Details URL : Internal (unless a process instance reference is available in the datastore source)

Connection Type: Datastore

Parameter : Select the parameter that should be used to display data

Query: The query that should run on the SSP7 database

Fields: On the Fields tab of the view settings, define the fields that are returned by the defined query and define how these fields are displayed in the view. Use the field names of the datastore parameter.

Type: Database query

To be completed

Type: Tickets

To be completed

View Fields

You need to define the fields manually. If a query contains 10 fields, they will not be placed in the view automatically.

  • Field type:

    • Key field: this field(s) will be used to uniquely define the record, in case the user goes into the detail screen

    • Text: normal fields

    • Date: not used anymore

    • Numeric: if only numbers are used

  • Source column: Column as it is named in the source query, or the datastore parameter, variable or form field.

  • Width: the width in pixels of the column in the view on dashboard. If 0, then no width style will be added

  • Default sort: sorting per field

  • Name in language: the name of the column that will appear on screen.

View fields details

On the view field details form, it can be configured how fields are displayed within the view.

Show on dashboard : Defines if the field is displayed in the dashboard view or not.

Field Type : Defines what kind of field is displayed. Most fields will be displayed as Text. To format dates correctly, select Timestamp for dates. The Key Field is used to identify if a field is to be used as the primary key of a view item.

Source Column : This contains an alias returned by the database query or the name of a SSP field in case of a Ticket Type view. *

Width : The number of pixels this column should be wide

Default Sort : Identifies if the field should be used for sorting and in which order that sort should be done. In case multiple sorts are defined on various fields, the field displayed most to the left is used as first order.

Translations : Defines the header displayed above a view column in all available languages.

* Source Column: The following sources can go into this field. Please note: this is case sensitive.

"ticketnr"

"ticketdatestarted"

"ticketdateended"

"ticketname"

"formname"

"ticketstatus"

"openstepname"

"allopenstepsname"

"openstepdatestarted"

"allopenstepsdatestarted"

"openstepdeadlinedate"

"allopenstepsdeadlinedate"

"openstepstatusimage"

"allopenstepsstatusimage"

"openstepactorname"

"openstepactordelegate"

"directapprovelink"

"directdeclinelink"

"directapproveanddeclinelink"

"requestedforuniqueid"

"requestedforfirstname"

"requestedforlastname"

"requestedforfirstandlastname"

"requestedforemail"

"requestoruniqueid"

"requestorfirstname"

"requestorlastname"

"requestorfirstandlastname"

"requestoremail"

"waitingforadditionalinfo"

"requestedfor-<personattr>"

"requestor-<personattr>"

"formfield-<internallabel>"

"extappfield-<internallabel>"

"stepfield-<pathtofield>"

"stepdate-<pathtostep>-<Started|Ended|Deadline>"

"stepactor-<pathtostep>-Name"

"wscallfield-<callname>-<fieldname>"

"variable-<varname>"

View fields overview

The fields available within the view definition are displayed in the list.

Manual XML Definition

The 2 types of views supported in SSP7 are Query views and Process views. Query views can be used to show lists from any internal are external database. These type of views are convenient to show content of connected third party systems. Process views are meant to show information from the SSP7 database. Views are always defined in XML files that can be edited by any text editor, for example Notepad. It is advised to always work from existing XML files, also in case new views are created.

XML File structure

All XML view definitions have the same structure, which is displayed below:

clip0017

The example above shows the 6 main components of a view definition. Each component is explained below:

  1. SQL Query, ConnectionType. Here you define what kind of database connection is to be made. Check the view types below to see what options are available

  2. SQL Query, ConnectionString. This contains the connection information to the database and is only used for Query Views.

  3. SQLQuery, CDATA. Here it is defined what information should be retrieved from the configured database connection. Content depends on the view type.

  4. CountQuery, CDATA. The count query is only used in Query Views and its result is displayed as number of lines in a view between () behind the view name on the dashboard.

  5. detailURL, 5.1. IsInternalDetail. This option is used to define if the details of a ticket should be retrieved from SSP internally or from data retrieved by the query. In case this option is set to 1, the process detail page will be displayed. In case the option is set to 0, the fields defined within the XML file will be displayed. Please note that for Process Views this option is ignored. 5.2. DetailInNewWindows. With this option, SSP7 can open a popup window when a user clicks on a line in the view. The popup will contain the ticket details. 5.3. CDATA. Defines the URL that should be displayed when a line is clicked. For Process Views this option is ignored.

  6. ViewLocal. This defines the name of the view as displayed on the dashboard. For each language this name can be defined. In case you are not certain about the number of a language (this number is defined with the database table "Language") you may prefer to change the name of the view with the edit page of views: clip0018

  7. Field. This is a repeated section within the view definition. For each field that should be displayed in the view, all field attributed should be defined. In case the option IsInternalDetail is set to 0, the fields defined here will also be displayed on the detail page. Size. With this option the width of the column in the view is defined in pixels. order. This option gives the possibility to set the ordering of views on certain fields. In case the value "Desc" is defined here, the view will have an initial descending ordering on the field. 7.1. Column. This field refers to a field, provided by the data in the SQLQuery. In case of Query views, this field should refer to a column (or alias) retrieved by the database query. For process views this should refer to one of the pre-defined fields that can be found under process views below. 7.2. type. Defined the type of field. Use the word "Key" to indicate that a column contains the unique identifier of records in the list. Other types are Date and Text. 7.3. positionInView. Defines on which position the field is displayed within the view and on the detail form. The field with the lowest number is shown on the left hand side of the view and on top of the details form (in case the option IsInternalDetail is set to 0). 7.4. displayInView. With this option it can be defined if the field should be displayed within the view. In case this option is set to False, the field will only be displayed on the details form (in case the option IsInternalDetail is set to 0). 7.5. FieldLocale. The label defined here will be displayed as name of the field within the view and details form. For each language another label can be used. The ID of a language is defined in the database table "Language".

Process Views

For details on the structure of the XML file, please check the section above. Per XML property, the options for process views are displayed below:

SQLQuery, connectiontype="Tickets"

SQLQuery, connectionstring can remain empty. This option is only used for query views.

SQLQuery, CDATA : First the general list content should be defined by selecting one of the following options:

  • MyOpenActions : show all open actions for the current logged in user. These are all the tickets where he is the Actor of the step that is now open in this ticket

  • MyClosedActions : show all recently closed actions for the current logged in user. These are all the tickets where he was an Actor in this ticket

  • MyTicketsAsRequestor : Show all open tickets where the logged in user was the Requestor, regardless of the Requested for.

  • MyTicketsAsRequestedFor : Show all open tickets where the logged in user was the Requested for, regardless of the Requestor.

  • EmailHasOpenActionInReminder : Steps that have sent a reminder can be used in combination with MyOpenActions

  • EmailHasOpenActionInEscalation1 : Steps that are in escalation 1

  • EmailHasOpenActionInEscalation2 : Steps that are in escalation 1

Then additional filters can be applied by adding any of the fields below on separate lines within the CDATA property:

  • TicketName=. When you enter a form title here, this View will only show tickets from the entered Form. If this field is not provided, the View will show tickets from all forms.

  • TicketStatus=. Enter ‘Open’ or ‘Closed’ if you want to differentiate between open & closed tickets. If this field is not provided, the View will show open & closed tickets.

  • TicketDateEnded=months:-3. Enter a value to set the time between the current data and the date the ticket ended, expressed in Months or Days. Enter ‘months’ or ‘days’, followed by the value. As a guideline, 3 months is a good value, as in the example above.

  • TicketDateStarted=days:-5. Enter a value to set the time between the current data and the date the ticket started, expressed in Days. Enter ‘months’ or ‘days’, followed by the value Fields to be shown.

  • TicketStatus=Open. The View will show all open tickets.

  • Field, column. Define the fields from the ticket that are shown in this View.

These are the options:

  • AllSteps : shows a graphical representation of the complete process, so all steps, each step has a color code to indicate the status. This is the same as how Tickets are shown in the Search Results. Each step is in it own column

  • AllStepsTogether : this method is nearly identical to the one above, only now all lights are merged into 1 column

  • AllSearchColumns: will show the columns as defined in Search Results Columns ( setting on Process level). Remark : this will only work if all tickets in this View result from the same Process.

  • TicketNr : the SSP number of the Ticket

  • TicketDateStarted : Start date of the Ticket

  • TicketDateEnded : End date of the ticket (if ticket is already closed)

  • TicketName : Name of the Process

  • TicketStatus : Indication is ticket is open or closed

  • OpenStepName : Name of the current active step

  • OpenStepDateStarted : Start date of current open step

  • OpenStepStatusImage : image ( colored light) to show status of current active step

  • RequestedForUniqueId : ID of the User for who the ticket was created

  • RequestedForFirstname : First Name of the User for who the ticket was created

  • RequestedForLastname : Last Name of the User for who the ticket was created

  • RequestedForFirstAndLastname : First Name & Last Name of the User for who the ticket was created

  • RequestedForEmail : Email of the User for who the ticket was created

  • RequestedFor- : Any other field of User for who the ticket was created, as defined in SSP

  • RequestorUniqueId : ID of the User who created the ticket

  • RequestorFirstname : First Name of the User who created the ticket

  • RequestorLastname : Last Name of the User who created the ticket

  • RequestorFirstAndLastname : First Name & Last Name of the User who created the ticket

  • RequestorEmail : Email of the User who created the ticket

  • Requestor- : Any other field of the User who created the ticket, as defined in SSP

Additionally, any Field from the Form that was used to create the ticket can be inserted. Internal labels as defined in the Form are used to refer to the fields. To add columns, showing these fields, simply add them, using this syntax:

  • Formfield-

Finally, you can enter fields from the Process

  • StepDate-||Started = Start date of the Step

  • StepDate-||Ended = End date of the Step

  • StepField-|| = Value of that Field

Where the path towards the target Step is, so the names of the Steps and DecisionPaths after each other, split by ||, following the structure of the process definition.

So, for example:

  • "StepField-New HR number||New employee number” : is the field "New employee number" from the Step "New HR number".

  • "StepDate-D1||Larger than 200||CIO Approval Step||Ended", Gives the end data of the Step "CIO Approval Step" in Decision path “Larger than 200" from step "D1". Always take the names form the default value.

Query Views

  • SQL Query, ConnectionType. Use the value "Internal" in case the SSP7 database is to be queried. When another database is queries, use Oracle or SQLServer as Connection Type.

  • SQL Query, ConnectionString. Use the same format here as within the adapter settings.

    • For Oracle this is an example string: "data source=ORCL;user id=ORCL;password=ORCL;persist security info=false/";

    • For SQL Server, this is the example: "data source=server;initial catalog=SMTXSSP7;User ID=SMTXSSP7;Password=SMTXSSP7;persist security info=False;packet size=4096"/>

  • SQLQuery, CDATA. Define here the SQL Query that retrieves the data from the configured connection. This query may contain the following variables:

    • $person_firstname$. Contains the logged in users first name

    • $person_lastname$. Contains the logged in users last name

    • $person_email$. Contains the logged in users email address

    • $person_$. Any of the defined custom user fields can be used here as variables.

  • CountQuery, CDATA. Use the exact same query condition here and replace the select part by SELECT COUNT(*) as Nmbr FROM.

  • detailURL,

    • CDATA. Define this URL if another URL than the standard URL should be called while opening the details of a ticket. An example URL is http://yourserver/SSP7/workflow/ProcessInstanceDetail.aspx?processInstanceId=$ID$&processInstanceGuid=$UniqueReference$ The variables like $processInstanceId$ are field names.

  • Field.

    • Column. Only use table columns or aliases returned by the query. In case incorrect names are used, the view will fail, resulting in a General Error on the dashboard page.

PreviousGroupsNextView Example 1

Last updated