Global definitions
Last updated
ProcMan Admin Guide V6.0.0
Last updated
A global definition serves to store shared settings of all process definitions which using this global definition. A change in a global definition has an immediate effect on all process definitions using it. Thus the process tables in the work list can differ depending on the settings in the global definitions (different count and heading of the columns) the processes using different global definitions are displayed in separate tables for each global definition in the work list.
By clicking on the Global definitions menu item the global definitions administration dialog is being started.
After the dialog has been started, the list of already defined global definitions is displayed (see picture below). If there are no global definitions defined a message informing about this fact is displayed instead.
This dialog can be left by clicking the Cancel button. It can also be left at any time, even in the global definition forms for new and edited global definitions, by selecting another function from the ProcMan menu. If this happens in the forms the last changes done in the forms are discarded.
A new global definition can be defined by clicking the New button in the global definitions list form. After that a form with the global definition fields appears (see picture below).
After filling the fields in this form and clicking the OK button the new global definition is created and appears in the global definitions list. By clicking the Cancel button the dialog returns to the global definitions list without creating a new global definition.
In the field Client the client in which the global definition will be created has to be selected.
The field Name has to be filled with the name of the new global definition. The name can contain simple alphanumerical characters (ä, š, ô, etc. are not allowed), underscores, dots and spaces. Spaces at the beginning and the end are ignored. After submitting the form the name is converted into uppercase.
The field Description can be filled with a textual description of the new global definition. It is a free text, which can contain any printable characters. It also can be left empty.
The check-box Enabled specifies whether the global definition can be used in ProcMan or not. If a global definition is not enabled it behaves like if it would not be defined at all.
Further fields are organized in sections. Each section can be opened or closed by clicking on the plus (+) or minus (-) control element in the front of the section title.
In this section process parameters can be defined which shall be displayed in the work list for all processes using this global definition. The values of these parameters can be filled by users in the dialog for process creation, in dialogs of process activities or evaluated and set by the process activities without a user interaction.
Moreover based on the parameter definitions in this section the process creation dialog is generated for processes using this global definition. The generated dialog provides users with entry fields for setting values of the process parameters. The look of these entry fields has also to be defined here.
The fields of this section can be edited when the section is open (see picture below).
The process parameters have to be defined in the displayed table. Each row of the table represents one parameter. In the top of the table standard process parameters are displayed with a gray background for which only fields in some columns are editable. In the bottom of the table new parameters specific for this global definition can be defined. Table rows can be added or deleted using the plus (+) and minus (-) buttons at the end of the rows.
The field Name has to be filled with the name of the parameter. The name can contain simple alphanumerical characters (ä, š, ô, etc. are not allowed), underscores, dots and spaces. Spaces at the beginning and the end are ignored. After submitting the form the name is converted into uppercase.
In the field Type the type of the parameter values has to be selected. The only difference between the types STRING and LONG_STRING is that the long string parameters are initially displayed in the work list in a slim column and the values of the parameters are shortened. By clicking on a control element in the column header the values are displayed in the full length and the column becomes as wide as needed.
The parameters of the type USER are displayed in the work list as links and by clicking on such a link the information about the user is shown in a popup window.
The parameters of the type STRING and NUMERIC can be defined to be displayed as links on pages of external systems (e.g. customer’s ticket system). By clicking on the button Extended right of the type selection field, a dialog is being displayed, where the link target can be defined as an expression. The expression syntax is the same like for the dialog element definition described later in this chapter. In the case that the value of the parameter shall be displayed as an read-only text (e.g. in the work list), it will be displayed as a link with the value of the evaluated expression as target, if the value of the evaluated expression is a string starting with 'http://' or 'https://'. Otherwise it is displayed as a normal text. The value of the parameter can be referenced in the expression by using the pseudo variable $. Currently other parameters cannot be referenced from the expression. For example, if there is defined for a STRING parameter X an link expression like this 'http://ticket.my_company.com:8080/ticket’.$.’.htm?mode=readonly’, the read-only value 123456 of the parameter X will be in the pages displayed as a link with the target: ‘http://ticket.my_company.com:8080/ticket123456.htm?mode=readonly’. When a user clicks on such link a new Window/Tab is opened where the link target page is displayed.
The field Description can be filled with a textual description of the parameter. It is a free text, which can contain any printable characters. It also can be left empty.
If the check-box Translate description is checked the value specified in the field Description is handled as an entry in the ProcMan’s dictionary and it is translated dependent on the current language settings any time before it is displayed. In this case the entry must be added into the /etc/dictionaries/hwm_custom_dictionary.xml file of the ProcMan installation.
If the check-box Translate parameter values is checked the value of the parameter is handled as an entry in the ProcMan’s dictionary and it is translated dependent on the current language settings any time before it is displayed. In this case entries for all possible parameter values must be added into the etc/dictionaries/hwm_custom_dictionary.xml file of the ProcMan installation.
In the field Search area a search area can be selected. Use the question mark (?) button for selection of the search class from a list. Use the Clear button to remove a selected search area from this field. In the case that a search area is set in this field the work list search function will search for texts in the values of this process parameter when the search area has been selected in the dialog of the search function.
The check-box Enabled specifies whether the parameter can be used in ProcMan or not. If a parameter is not enabled it behaves like if it would not be defined at all.
The check-box Show in process dialog specifies whether an entry field shall be generated for this parameter in the process creation dialog.
In the case that an entry field shall be generated for the parameter in the process creation dialog, the properties of the entry field can be defined when clicking the Edit button in the Process dialog attributes column. After clicking the Edit button a dialog appears (see picture below).
After filling the fields in this form and clicking the OK button the definition of the entry field is passed to the dialog for a new global definition. Beware that the entry field definition is not persistently saved at this moment. It is saved only when the whole global definition is created by clicking the OK button in the calling dialog. By clicking the Cancel button the dialog returns to the calling dialog for the global definition discarding all settings done in it.
The read-only fields Name and Type in the top of the form inform about the name and the type of the parameter for which the dialog entry field shall be defined.
The rest of the form is divided into sections. The sections allow defining of different look and functionality of the entry field depending on the context defined by the logged in user, the role in which he is currently working and the client in which he is logged in. For example it can be defined that the entry field is in processes of one client displayed as an editable text and in another client as a selection box with predefined values, and/or the entry field is for one role editable but for another role read-only. Each section is displayed as a line with a plus (+) / minus (-) control element at the beginning for opening / closing the section and followed by Client, Role and User fields.
The client, role and user fields have to be filled with pattern strings which are checked at the time the entry field shall be generated. The entry field definition in the first section, in which the current context is matching the patterns, is used for the generation. If no such section has been found defaults depending on the type of the parameter are used for the entry field generation. The patterns can contain wildcards: asterisk (*) and question mark (?). Asterisk means any string even an empty. Question mark means any character. If asterisk or question mark are not meant as wildcards but characters appearing in the value, they must be escaped with a backslash (\) like this: \*, \?. Also if a backslash is meant as a character appearing in the value it must be escaped like this: \\.
Right of the client, role and user field is a button with a question mark (?). By clicking the button defined clients, roles or users can be selected and filled into the fields from a list in a popup window. The user field has moreover right of the button with the question mark two further buttons: plus (+) and minus (-) which allow adding further or delete user patterns in the section. When it is checked whether the current context is matching the section patterns, in the case of user patterns is checked whether the name of the logged in user is matching at least one of the specified patterns.
Initially there is only one section in which all the pattern fields are filled with asterisk so any context would match the patterns of this section. If this is expected the entry field definition can be done in this section and it will be used any time the entry field is generated. Otherwise the patterns in the initial section can be changed, further sections can be added or deleted using the plus (+) or minus (-) buttons at the end of the section row and the entry field definition can be done in every section.
Which form fields for the entry field definition are displayed in the sections is dependent on the type of the process parameter.
If the check-box in the field Hidden is checked the entry field is generated and filled with a default value but not visible.
If the check-box in the field Readonly is checked the generated entry field is only for reading.
If the check-box in the field Mandatory is checked the value entered by the user in the generated entry field must not be empty which is being verified automatically. The generated entry field has in this case a light blue background color.
If the check-box in the field Width selection button is checked right of the generated entry field a question mark (?) button is displayed. By clicking on the question mark button a selection popup window is displayed in which the user can select the value he wants to fill into the entry field.
In the field Type the type of the generated entry field has to be selected. If the type is text a single line text input element is generated. If the type is multiline a multiline text input element is generated. If the type is selection a selection box with predefined values is generated. If the type is checkbox a check-box is generated.
In the field Size can be specified how many characters wide the generated single line text input element shall be. If none is specified a default value is used.
In the field Rows can be specified how many rows high the generated multiline text input element shall be. If none is specified a default value is used.
In the field Width can be specified how many characters wide the generated multiline text input element shall be. If none is specified a default value is used.
In the field Maximal length can be specified the maximal count of entered characters in the generated single line or multiline text input element. If none is specified there is no limit set in the element.
In the field List of possible values the values which can be selected in the generated selection box have to be specified. For adding/deleting lines in the list the plus (+) and minus (-) buttons right of the value fields can be used.
The string value specified in the option Custom Data type is used at the dialog generation time, for selecting entries, having this value in the first column (data_type), from the database table custom_data. The data rows selected this way from the database are then used for adding selection options in the generated selection box. For each row selected this way, one additional selection option is being generated. Following rules are applied for adding of the selection options:
1. The first not empty value in the string columns (data_str_1, data_str_2, ..., data_str_6) of a row is used as the value (what is set on selection as the parameter value) of the newly generated option.
2. The second not empty value in the string columns (data_str_1, data_str_2, ..., data_str_6) of a row is used as the description (what the user sees in the selection box) of the generated option.
3. If only one of the string columns (data_str_1, data_str_2, ..., data_str_6) of a row contains a not empty value, then this value is used for both, the value and the description of the generated option.
4. If the rows have different values in the integer columns (data_int_1, data_int_2), the values are used for sorting the entries from the smallest to the greatest, for generating the options in the sorted order.
5. If the rows have same values in the integer columns (data_int_1, data_int_2), the generated options are sorted by the description.
If the check-box in the field By default checked is checked the generated check-box is initially checked, otherwise not.
In the field Value when checked the textual value which shall be set into the process parameter when the generated check-box is checked has to be specified.
In the field Value when unchecked the textual value which shall be set into the process parameter when the generated check-box is not checked has to be specified.
If the check-box in the field Ignore calendar settings is checked the value the user entered in the generated entry field for a process parameter of type DATE is not checked whether it is a working date due to the settings done in the used calendar.
In the field Offset days can be specified how many working days in the future the value in the generated entry field of a process parameter of type DATE must be set by the user. If no offset days value is specified the value in the entry field can be set with a date even in the past. If the offset days value is greater or equal 0, the date value in the entry field must be at least the current date plus count of days specified in the offset days value or later.
In the field Increment offset days after a time value can be specified. If it is empty the value in the Offset days field is being used every time for counting the next possible date value in the generated entry field. If it is not empty every day after reaching the time specified here the value in the Offset days field incremented by one more day is being used every time for counting the next possible date value in the generated entry field.
If the check-box in the field Time for UTC conversion (From the next TIME parameter) is checked the process parameter of type DATE is coupled with the next defined process parameter of type TIME. Through this coupling the values which the user enters in the generated entry fields for both process parameters are handled as the date and time part of a timestamp. The timestamp is converted by ProcMan in the UTC timezone and the values of the process parameters are stored in this form.
In the field Time for UTC conversion (otherwise) a time value can be specified. If the process parameter of type DATE is not coupled with the next defined process parameter of type TIME, or the value in the entry field generated for the TIME parameter is missing for some reason, the time value specified here is used as the time part of the timestamp for the UTC conversion.
If the check-box in the field Date for UTC conversion (From the previous DATE parameter) is checked the process parameter of type TIME is coupled with the previously defined process parameter of type DATE. Through this coupling the values which the user enters in the generated entry fields for both process parameters are handled as the date and time part of a timestamp. The timestamp is converted by ProcMan in the UTC timezone and the values of the process parameters stored in this form.
In the field Default value the default value which shall be initially set for the generated entry field can be specified.
If the check-box in the field Evaluate default value is checked the text in the field Default value is handled as an expression (the expression syntax is described later in this chapter). In this case the expression is evaluated every time the entry field is generated and the result of the evaluation is used as the default value of the generated entry field.
In the field Triggering of dynamic dialog parts can be specified that some parts of the generated dialog will only be shown depending on a fulfillment of specified conditions. Each such dynamic part is represented by a row in the table in this field. Rows can be added or removed using the plus (+) and minus (–) buttons in the end of each row. In the Title field a text can be specified which appears as a heading when the part is shown. If it is empty no heading will be shown. If the check-box in the Translate field is checked the title is handled as a key in the dictionary and translated to the proper language depending on the user’s language settings. In this case the entry must be added into the etc/dictionaries/hwm_custom_dictionary.xml file of the ProcMan installation. The value of the field Parameter Prefix specifies the name prefix of parameters which belong to the dynamic part. If the expression (the expression syntax is described later in this chapter) specified in the Condition field is fulfilled (its evaluation returns a value interpreted as a logical true), the dynamic part is displayed, otherwise it is hidden.
If the check-box in the field Do not check whether user exists is checked the value entered in the generated entry field for a process parameter of the type USER is not check whether it is a known user name in ProcMan.
In the field Role one or more roles can be specified. The question mark (?) button right of the value field can be used to select a role from a list displayed in a popup window. For adding/deleting further roles the plus (+) and minus (-) in the right of each role line can be used. If one or more roles are specified, it is checked whether the user, of which user name the user entered in the generated entry field, has one of the roles specified here.
In the field Input value verification condition an expression (the expression syntax is described later in this chapter) can be specified for to verify the value entered by the user in the generated entry field. The evaluation of the expression takes place every time the form in which the entry field has been generated is being submitted by a user. If none expression is specified no verification takes place. If it is specified and the evaluation of the expression returns a value which is interpreted as a logical false, an error message is displayed and the user must correct the input value before he can continue.
In the field Error message when verification failed a message text can be specified which is displayed when the evaluation of the verification condition returns a value which is interpreted as a logical false. If none specified a default message is displayed in this case.
If the check-box in the field Translate (Error message when verification failed) is checked the value specified in the field Error message when verification failed is handled as an entry in the ProcMan’s dictionary and it is translated dependent on the current language settings any time before it is displayed. In this case the entry must be added into the /etc/dictionaries/hwm_custom_dictionary.xml file of the ProcMan installation.
In the field Input value second verification condition an expression (the expression syntax is described later in this chapter) can be specified for to verify the value entered by the user in the generated entry field. The evaluation of the expression takes place every time the form in which the entry field has been generated is being submitted by a user. If none expression is specified no verification takes place. If it is specified and the evaluation of the expression returns a value which is interpreted as a logical false, a warning message is displayed and the user can correct the input value or continue without changing the value.
In the field Warning message when verification failed a message text can be specified which is displayed when the evaluation of the second verification condition returns a value which is interpreted as a logical false. If none specified a default message is displayed in this case.
If the check-box in the field Translate (Warning message when verification failed) is checked the value specified in the field Warning message when verification failed is handled as an entry in the ProcMan’s dictionary and it is translated dependent on the current language settings any time before it is displayed. In this case the entry must be added into the /etc/dictionaries/hwm_custom_dictionary.xml file of the ProcMan installation.
In the field Help text a help text can be specified which is being displayed right of the generated entry field.
If the check-box in the field Translate (Help text) is checked the value specified in the field Help text is handled as an entry in the ProcMan’s dictionary and it is translated dependent on the current language settings any time before it is displayed. In this case the entry must be added into the etc/dictionaries/hwm_custom_dictionary.xml file of the ProcMan installation.
Like described above expressions can be used in the definition of a generated entry field which are evaluated every time when the field is generated to initialize its value and when the form with the field is submitted by a user to verify the value entered in the field. Following elements can be used in the expressions:
Literals – string literals (starting and ending with a single quote ('), backslash () is used for escaping special characters), decimal numeric literals (using point (.) as a decimal delimiter), Boolean literals (true and false)
Operators – arithmetic operators (+, -, *, /, % (modulus)), bitwise operators (&, |, ^ (xor), ~ (not), << (shift left), >> (shift right)), comparison operators (=, == ,!=, <>, <, >, <=, >=), logical operators (!, not, &&, and, ||, or, xor), string concatenation operator (.))
Parentheses – for sub expressions
Conditional expression – condition ? expr1 : expr2 – If the condition is evaluated as a Boolean true then the conditional expression returns the result of the evaluation of the expression expr1, otherwise it returns the result of the evaluation of the expression expr2.
Type casting – (string), (int) and (float)
Parameter references - $ references the value of this process parameter, ${name} references the value of the process parameter with the specified name, ${name=literal} references the value of the process parameter with the specified name using the default value specified in the literal if the process parameter is unknown. For the standard process parameters the following names can be used: !GROUP, !DESCRIPTION, !PREDECESSOR, !EARLIEST_DATE, !EARLIEST_TIME, !LATEST_DATE, !LATEST_TIME, !MEMO.
Function calls – name(parameter list) calls the function specified by the name with the parameters specified in the parameter list.
in(string | int, …) – Checks whether the value of the first parameter (needle) is equal to a value in one of the further parameters (haystack). Returns true if the needle has been found in the haystack, false otherwise.
trim(string) – Returns a string which is produced from the input string by removing whitespaces at the beginning and at the end.
ltrim(string) or lefttrim(string) – Returns a string which is produced from the input string by removing whitespaces at the beginning.
rtrim(string) or righttrim(string) – Returns a string which is produced from the input string by removing whitespaces at the end.
concat(string, …) or strconcat(string, …) – Returns a string which is produced as a concatenation of all strings passed in the parameters. Alternatively the string concatenation operator (.) can be used instead of calling this function.
upper(string), toupper(string) or strtoupper(string) – Returns a string which is produced from the input string by changing all alphabetical characters into upper case.
lower(string), tolower(string) or strtolower(string) – Returns a string which is produced from the input string by changing all alphabetical characters into lower case.
len(string), length(string) or strlen(string) – Returns the length of the input string.
substr(string, int [, int]) or substring(string, int [, int]) – Returns a substring of the input string in the first parameter from the zero based position in the second parameter to the end of the string or with the length specified in the optional third parameter.
pos(string, string [, int [, bool]]), position(string, string [, int [, bool]]) or strpos(string, string [, int [, bool]]) – Returns the index of the first/last (dependent on the fourth parameter) occurrence of the string in the second parameter in the string in the first parameter. If the optional third parameter is passed to the function the search starts at the position specified by this parameter. If the fourth parameter is not specified or false, the function returns the index of the first occurrence, if the parameter is true, the function returns the index of the last occurrence.
match(string, string) or strmatch(string, string) – Returns true if the string in the second parameter matches the pattern string in the first parameter, or false otherwise. The pattern string can contain wildcards asterisk () which means any string (even an empty string) and question mark (?) which means any character. The backslash () can be used for escaping special characters (, ? and ) in the pattern string.
eol() or eoln() – Returns a string containing only the end of line character.
translate(string) or trnsl(string) or trnslt(string) – Returns the dictionary translation of the in the parameter specified dictionary key according to the user’s language setting.
date([bool [,string [, string [, bool [, bool]]]]]) – Returns a date string. If the optional first parameter is true the returned date is formatted using the date format specified in the ProcMan’s Options dialog. If the optional first parameter is omitted or false the returned date is formatted using the YYYYMMDD format. If the optional second parameter is omitted or null the current date (or reference date if specified in the third parameter) is returned. If the optional second parameter is a string containing one or more substrings like this ‘<sign><number><units>’ where <sign> is plus (+) or minus (-), <number> is a positive integer and <unit> is one of Y, YEAR, YEARS, M, MONTH, MONTHS, D, DAY, DAYS, H, HOUR, HOURS, I, MI, MIN, MINUTE, MINUTES, S, SEC, SECOND or SECONDS (e.g. ‘+1Year -2Hours -30Minutes’) the offset is applied on the current timestamp (or reference timestamp if specified in the third parameter) and the date part of the evaluated timestamp is returned. If the optional third parameter is omitted or null the current timestamp is used as the reference timestamp. If the optional third parameter is a string containing a valid timestamp, date or time, the value specified in this parameter is used as the reference timestamp (the current date is used if the date part is missing, 12:00:00 is used if the time part is missing). Although the function accepts various timestamp formats we recommend to pass timestamp values in YYYYMMDDHHMMSS format, date values in YYYYMMDD format and time values in HHMMSS format in this parameter, to avoid eventual problems when users are using different date formats. If the optional fourth parameter is omitted or true the reference timestamp in the third parameter is handled as in the UTC time zone. If it is false the reference timestamp is handled as in the user’s time zone. The difference is, that a reference timestamp in UTC time zone specifies for all users, regardless on in which time zone they are, the same time, while a reference timestamp in user’s time zone specifies the time depending on the time zone the users are in (e.g. 12:00:00 in Berlin is at a different time than 12:00:00 in Tokyo). If the optional fifth parameter is omitted or false, the output is converted into user’s time zone. If it is true the output is converted into UTC time zone. As all the timestamp/date/time values in the dialogue are handled in user’s time zone, the only meaningful case when to set this parameter to true is, if the output of this function is passed in a parameter of another function, expecting the parameter value in UTC time zone.
time([bool [,string [, string [, bool [, bool]]]]]) – Returns a time string. If the optional first parameter is true the returned date is formatted using the HH:MM:SS format. If the optional first parameter is omitted or false the returned date is formatted using the HHMMSS format. If the optional second parameter is omitted or null the current time (or reference time if specified in the third parameter) is returned. If the optional second parameter is a string containing one or more substrings like this ‘<sign><number><units>’ where <sign> is plus (+) or minus (-), <number> is a positive integer and <unit> is one of Y, YEAR, YEARS, M, MONTH, MONTHS, D, DAY, DAYS, H, HOUR, HOURS, I, MI, MIN, MINUTE, MINUTES, S, SEC, SECOND or SECONDS (e.g. ‘+1Year -2Hours -30Minutes’) the offset is applied on the current timestamp (or reference timestamp if specified in the third parameter) and the time part of the evaluated timestamp is returned. If the optional third parameter is omitted or null the current timestamp is used as the reference timestamp. If the optional third parameter is a string containing a valid timestamp, date or time, the value specified in this parameter is used as the reference timestamp (the current date is used if the date part is missing, 12:00:00 is used if the time part is missing). Although the function accepts various timestamp formats we recommend to pass timestamp values in YYYYMMDDHHMMSS format, date values in YYYYMMDD format and time values in HHMMSS format in this parameter, to avoid eventual problems when users using different date formats. If the optional fourth parameter is omitted or true the reference timestamp in the third parameter is handled as in the UTC time zone. If it is false the reference timestamp is handled as in the user’s time zone. The difference is, that a reference timestamp in UTC time zone specifies for all users, regardless on in which time zone they are, the same time, while a reference timestamp in user’s time zone specifies the time depending on the time zone the users are in (e.g. 12:00:00 in Berlin is at a different time than 12:00:00 in Tokyo). If the optional fifth parameter is omitted or false, the output is converted into user’s time zone. If it is true the output is converted into UTC time zone. As all the timestamp/date/time values in the dialogue are handled in user’s time zone, the only meaningful case when to set this parameter to true is, if the output of this function is passed in a parameter of another function, expecting the parameter value in UTC time zone.
ts([bool [,string [, string [, bool [, bool]]]]]) or timestamp([bool [,string [, string [, bool [, bool]]]]]) – Returns a timestamp string. If the optional first parameter is true the date part of the returned timestamp is formatted using the date format specified in the ProcMan’s Options dialog, there is a space between the date and the time part and the time part of the returned timestamp is formatted using the HH:MM:SS format. If the optional first parameter is omitted or false the returned timestamp is formatted using the YYYYMMDDHHMMSS format. If the optional second parameter is omitted or null the current timestamp (or reference timestamp if specified in the third parameter) is returned. If the optional second parameter is a string containing one or more substrings like this ‘<sign><number><units>’ where <sign> is plus (+) or minus (-), <number> is a positive integer and <unit> is one of Y, YEAR, YEARS, M, MONTH, MONTHS, D, DAY, DAYS, H, HOUR, HOURS, I, MI, MIN, MINUTE, MINUTES, S, SEC, SECOND or SECONDS (e.g. ‘+1Year -2Hours -30Minutes’) the offset is applied on the current timestamp (or reference timestamp if specified in the third parameter) and the evaluated timestamp is returned. If the optional third parameter is omitted or null the current timestamp is used as the reference timestamp. If the optional third parameter is a string containing a valid timestamp, date or time, the value specified in this parameter is used as the reference timestamp (the current date is used if the date part is missing, 12:00:00 is used if the time part is missing). Although the function accepts various timestamp formats we recommend to pass timestamp values in YYYYMMDDHHMMSS format, date values in YYYYMMDD format and time values in HHMMSS format in this parameter, to avoid eventual problems when users are using different date formats. If the optional fourth parameter is omitted or true the reference timestamp in the third parameter is handled as in the UTC time zone. If it is false the reference timestamp is handled as in the user’s time zone. The difference is, that a reference timestamp in UTC time zone specifies for all users, regardless on in which time zone they are, the same time, while a reference timestamp in user’s time zone specifies the time depending on the time zone the users are in (e.g. 12:00:00 in Berlin is at a different time than 12:00:00 in Tokyo). If the optional fifth parameter is omitted or false, the output is converted into user’s time zone. If it is true the output is converted into UTC time zone. As all the timestamp/date/time values in the dialogue are handled in user’s time zone, the only meaningful case when to set this parameter to true is, if the output of this function is passed in a parameter of another function, expecting the parameter value in UTC time zone.
weekday(string) – Returns the numeric representation of the week day (0 = Sunday through 6 = Saturday) of the date specified in the parameter, or -1 on error.
freeday(string [, bool]) – Returns true if the date specified in the first parameter is a free day according to the current calendar, otherwise it returns false. If the optional second parameter is false free days marked in the calendar as selectable (allow selection) are considered not to be free days and the function returns false for them.
workday(string [, bool]) – Returns true if the date specified in the first parameter is a work day according to the current calendar, otherwise it returns false. If the optional second parameter is true free days marked in the calendar as selectable (allow selection) are considered to be work days and the function returns true for them.
addworkdays(bool, int [, bool [, string]]) – Adds the count of work days specified in the second parameter to the current date (or reference date if specified in the fourth parameter) according to the current calendar and returns the final date as a string. If the first parameter is true the returned date is formatted using the date format specified in the ProcMan’s Options dialog. If the first parameter is false the returned date is formatted using the YYYYMMDD format. If the optional third parameter is omitted or false also a selectable free day can be returned. If it is true only a workday can be returned. If the optional fourth parameter is omitted or null the current date is used as the reference date for the evaluation. If it is a string containing a valid date the specified date is used as the reference date for the evaluation. Although the function accepts various date formats we recommend to pass date values in YYYYMMDD format in this parameter, to avoid eventual problems when users are using different date formats.
timestampreached(string [, bool]) or tsreached(string [, bool]) – Returns true if the time specified as a timestamp in the first parameter is a time in the past or the current time, otherwise it returns false. Although the function accepts various timestamp formats we recommend to pass timestamp values in YYYYMMDDHHMMSS format, to avoid eventual problems when users are using different date formats. If the optional second parameter is missing or true, the timestamp is handled as an UTC time, otherwise as a local time.
datetimereached(string, string [, bool]) or dtreached(string, string [, bool]) – Returns true if the time specified by the date int the first parameter and the time in the second parameter is a time in the past or the current time, otherwise it returns false. The date can be specified as a date value or a timestamp value. The time can be specified as a time value or a timestamp value. Although the function accepts various timestamp formats we recommend to pass timestamp values in YYYYMMDDHHMMSS format, date values in YYYYMMDD format and time values in HHMMSS format in this parameters, to avoid eventual problems when users are using different date formats. If the optional third parameter is missing or true, the timestamp built from the date and time is handled as an UTC time, otherwise as a local time.
client() – Returns the name of the process client.
user() – Returns the name of the current user.
userdescr() or userdescription() – Returns the description of the current user.
role() – Returns the name of the role in which the current user is currently working.
param(string) or processparam(string) – Returns the current string value of the ProcMan process parameter having the parameter ID specified in the function parameter. If the parameter ID is unknown or the parameter has no value yet it returns an empty string.
paramdate(string) or processparamdate(string) – Returns the current string value of the ProcMan process date parameter having the parameter ID specified in the function parameter. The returned date is formatted using the date format specified in the Options dialog of the current user. If the function cannot return a valid date for some reason (unknown parameter ID, not a date parameter, missing value for the parameter, etc.) it returns an empty string.
paramtime(string) or processparamtime(string) – Returns the current string value of the ProcMan process time parameter having the parameter ID specified in the function parameter. The time (internally stored in UTC) is converted in the time zone of the current user before it is returned. The returned time is in the format HH:MM:SS. If the function cannot return a valid time for some reason (unknown parameter ID, not a time parameter, missing value for the parameter, etc.) it returns an empty string.
mapcustomdata(string, string [, string, string|int [, string, string|int [, …]]]) – This function searches for the specified key in the data stored in ProcMan’s database table custom_data and on success it returns the required value at the specified column. The first parameter is the type of the data. The function will search only for records having the specified value in the data_type column of the database table. The second parameter is the name of the table column, from which the value returned by the function shall be read, from the found record. One of the following values can be specified in the parameter: 'data_int_1', 'data_int_2', 'data_str_1', 'data_str_2', …, 'data_str_6'. The optional further parameters specify the key of the database table record which should be searched for. The key parameters are expected to be specified as pairs, where the first parameter in a pair is the key column name and the second one is the key value. The function searches then for records having the key value in the key column specified by the name. The key column name can be one of the values specified above for the second function parameter. If the key of the searched record consists of several columns, several pairs of key column name and key value can be specified in further parameters (see example below). If the function does not find any record matching the specified type and/or key, the function returns the value false.
searchcustomdata(string [, string, string|int [, string, string|int [, …]]]) – This function searches for the specified key in the data stored in ProcMan’s database table custom_data and on success it returns the value true, otherwise it returns the value false. The first parameter is the type of the data. The function will search only for records having the specified value in the data_type column of the database table. The optional further parameters specify the key of the database table record which should be searched for. The key parameters are expected to be specified as pairs, where the first parameter in a pair is the key column name and the second one is the key value. The function searches then for records having the key value in the key column specified by the name. The key column name can be one of the following values: 'data_int_1', 'data_int_2', 'data_str_1', 'data_str_2', …, 'data_str_6'. If the key of the searched record consists of several columns, several pairs of key column name and key value can be specified in further parameters.
mapcustomdataregex(string, string, string, string [, string, string|int [, string, string|int [, …]]]) – This function searches for the specified key in the data stored in ProcMan’s database table custom_data. For each value in the specified column of found records, it applies a filter function, which replaces placeholders in the specified regular expression with the found value and checks, whether the regular expression matches the specified reference value. If this is the case for some found value, it returns this value. The first parameter is a regular expression which may contain one or several placeholders <param>, specifying where values selected from the custom_data table have to be placed. The second parameter is the reference value, which shall match the regular expression. The third parameter is the type of the data. The function will search only for records having the specified value in the data_type column of the database table. The fourth parameter is the name of the table column, from which the value returned by the function shall be read, from the found record. One of the following values can be specified in the parameter: 'data_int_1', 'data_int_2', 'data_str_1', 'data_str_2', …, 'data_str_6'. The optional further parameters specify the key of the database table records which should be searched for. The key parameters are expected to be specified as pairs, where the first parameter in a pair is the key column name and the second one is the key value. The function searches then for records having the key value in the key column specified by the name. The key column name can be one of the values specified above for the second function parameter. If the key of the searched record consists of several columns, several pairs of key column name and key value can be specified in the further parameters (see example below). If the function does not find any record matching the specified type and/or key, or if for none of the values in the found records in the specified column the regular expression matches the reference value, the function returns the value false.
searchcustomdataregex(string, string, string, string [, string, string|int [, string, string|int [, …]]]) – This function works in the same way like mapcustomdataregex (see description above). The only difference is, that instead of the found value it returns true on success.
replacecustomdata(string, bool, string, string, string, string, string [, string, string|int [, string, string|int [, …]]]) – This function searches for the specified key in the data stored in ProcMan’s database table custom_data. For each value pair <needle, value> in the specified columns of found records, it replaces the occurrences of needle in a specified string with the value. It returns the string containing the replacements, or the original string if no replacements have been found. The first parameter is the string in which the replacements shall be done. If the second parameter is true, the search for the replacements is case sensitive, if it is false, the search is case insensitive. The third parameter is the needle prefix. The fourth parameter is the needle suffix. On the search for the replacements, the function searches for strings made as a concatenation of the prefix, the needle and the suffix. The needle prefix and/or suffix parameters can be set to an empty string, if the needles does not need to be searched in a specific prefix and/or suffix context. The fifth parameter is the type of the data. The function will search only for records having the specified value in the data_type column of the database table. The sixth parameter is the name of the column, in which the custom data table records contain the needles. The seventh parameter is the name of the column, in which the custom data table records contain the values for the replacement of needles. One of the following values can be specified in the sixth and seventh parameters: 'data_int_1', 'data_int_2', 'data_str_1', 'data_str_2', …, 'data_str_6'. The optional further parameters specify the key of the database table records which should be searched for. The key parameters are expected to be specified as pairs, where the first parameter in a pair is the key column name and the second one is the key value. The function searches then for records having the key value in the key column specified by the name. The key column name can be one of the values specified above for the sixth/seventh function parameter. If the key of the searched record consists of several columns, several pairs of key column name and key value can be specified in the further parameters (see example below).
Here are some examples of usage of expressions:
The above expression can be used for an initialization of a text entry field with a value starting with the client name, continuing with underscores (_) and being 16 characters long.
The above expression can be used for verifying the values entered in a text entry field. The verification would accept only values having 10 or more characters starting with the client name and values having exactly 18 characters and ending with the value specified in the field Group ID.
The above expression can be used for an initialization of a date entry field. If the current day is the 15th day of the current month or lower the date field is initialized with the date one week later, otherwise it is initialized with the date two weeks later. Moreover, the initial date is formatted in the format set for the user.
The above expression searches in the ProcMan’s database table custom_data for a record which has the value 'DEPARTMENT NAME PREFIX' in the column data_type, the value 'R&D' in the column data_str_1 and the value 'UNIT 317' in the column data_str_2. If it finds such a record, it returns the value of the column data_str_3 of the record. If such a record cannot be found in the database table, it returns the value false.
The above expression searches in the ProcMan’s database table custom_data for records which have the value 'STAGE' in the column data_type and the value 'TEST' in the column data_str_1. If it finds such records and some of the records has the value 'PROD' in the column data_str_2, the function returns the value 'PROD', because the regular expression in the first parameter matches the reference value in the second parameter for this value. If none record was found, having a value in the column data_str_2, for which the regular expression would match the reference value, it returns the value false.
The above expression searches in the ProcMan’s database table custom_data for records which have the value 'STAGE' in the column data_type and the value 'PROD' in the column data_str_1. If it for example finds two records, a record having the value 'part1' in the column data_str_2 and the value 'x1' in the column data_str_3 and a record having the value 'part3' in the column data_str_2 and the value 'x3' in the column data_str_3, it returns the string '.x1.part2.x3.part4.'.
The key words (e.g. and, string, etc.) and function names in the expressions are case insensitive.
Expressions can be debugged by prepending them with the debug or the dbg key word. For example:
In this case the expression is evaluated in a normal way and in addition a debug information about the evaluation is being written into the hwm-expression-<current_date>.log file in the ProcMan’s log directory. The debug information contains the original expression, the expression generated for the evaluation from the original expression, the parameter and the context parameters passed to the evaluation and either the result of a successful evaluation, or the error message of a failed evaluation.
In this section can be specified whether external files (e.g. pdf, doc, ppt, etc.) can be attached to processes using this global definition or not.
The fields of this section can be edited when the section is open (see picture below).
If the check-box in the field Allow attachment of files is checked it will be allowed to attach external files to processes using this global definition.
In this section it can be specified what status of activities of all processes using this global definition shall be set dependent on the returned control code of the actions executed by the activities. The control codes in ProcMan are strings. To set a control code the programs executed by an action has to call the API function hwm_set_return_code (the function is described in httpd/htdocs/hwm_api.php where it is defined).
The definitions done in this section are to be seen as defaults which can be overridden for each process activity. Defining the most common (or even all if possible) mappings of control codes to activity statuses here spares a lot of definition work by avoiding the necessity of repeating the same specifications in all process definitions or even for all activities in the process definitions using the global definition.
The fields of this section can be edited when the section is open (see picture below).
The input fields in the section are organized in a table where each row represents a single condition. Condition rows can be added or deleted using the plus (+) or minus (-) buttons at the end of each row. There can be more conditions setting the same status of activities defined. Beware that there should not be more conditions which are true for the same control code otherwise it is not clear which condition will be applied for setting the activity status, as the order in which the conditions are evaluated is not fix.
In the field Set Status the activity status has to be selected which shall be set when the control code returned by an action fulfills the condition.
In the field Condition the operator has to be selected which shall be applied to compare the control code returned by an action with the parameters of the condition.
In the fields Condition Parameter 1 and Condition Parameter 2 the parameters of the condition operator has to be specified. Two parameters are used only for operators testing whether the control code returned by an action is within or without a range. By other operators the second parameter is ignored. Beware that the parameters are handled as integers only if the value of the control code as well as the values of the parameters contain only digits. Otherwise they are handled as strings.
In this section can be specified in which cases generated e-mail messages shall be sent to which users. Sending of messages in two situations can be defined here: when the status of a process of this global definition has been changed and when the status of an activity of a process of this global definition has been changed.
The definitions done in this section for sending messages when the status of activities has been changed are to be seen as defaults which can be overridden for each process activity. Defining the most common (or even all if possible) message sending rules here spares a lot of definition work by avoiding the necessity of repeating the same specifications in all process definitions or even for all activities in process definitions using the global definition.
Beware that e-mails can be sent only if an SMTP server has been configured after the ProcMan installation (please refer to the ProcMan installation and customize guide for more information). Moreover e-mails can only be sent to users which have an e-mail address specified in their accounts.
The fields of this section can be edited when the section is open (see picture below).
The input fields in this section are organized in two tables: one for processes and one for activities. Each row in these tables describes to whom a message shall be sent in the case that a process or an activity changes its status. Rows can be added or deleted by clicking the plus (+) or minus (-) buttons at the end of each row in both tables.
In the field When Status the status has to be selected for to specify that when a process or an activity changes to this status a message shall be sent.
If the check-box in the field Message Process Creator is checked a message informing the process creator user is sent when the process becomes the selected status.
If the check-box in the field Message Users which completed start activities is checked a message informing the users which completed the start activities of the process is sent when the process becomes the selected status.
If the check-box in the field Message last update User of activities is checked a message informing the users which completed all activities of the process is sent when the activity becomes the selected status.
If the check-box in the field Message last update User of successor activities is checked a message informing the users which completed the successor activities of the process is sent when the activity becomes the selected status.
In the field Message other user a user name of the user which shall be informed by a message when the process or activity becomes the selected status can be specified. Clicking the question mark (?) button right to the text input field allows selecting the user from a list which appears in a popup window. The user entered here can also be a special user dedicated only for this purpose which has no role assigned and/or having a collective e-mail address (the e-mails sent to this address are delegated by the mail server to further addresses) specified in he’s account.
When a user is creating a process of this global definition, editing it, working in an activity of it or viewing the report for it he can open the process documentation by clicking the documentation icon in the top of the ProcMan window (see picture below). In this case the process documentation is generated from the entries done in this section and from the entries done in the documentation section of the process definition.
The process documentation is organized in chapters which can contain a multiline plain text, but no objects like pictures, tables, etc.
The fields of this section can be edited when the section is open (see picture below).
Chapter specifications are displayed as table rows. Rows can be added or deleted by clicking on the plus (+) or minus (-) buttons at the end of each row.
In the field Title the title of the chapter has to be specified which shall be displayed in the generated documentation.
In the field Language the language of the chapter specification has to be selected. If a value other than asterisk () is selected, the chapter will appear in the generated documentation only if the calling user has the same language set in the ProcMan options. If the value asterisk () is selected here, the chapter will appear in the generated documentation independent of what language the calling user has set in the ProcMan options.
The fields Client, Role and User have to be filled with pattern strings which are checked at the time the documentation shall be generated. The generated documentation will contain only those chapters for which the process client, the role in which the current user is currently working and the user name of the current user are matching the patterns specified here. The patterns can contain wildcards: asterisk (*) and question mark (?). Asterisk means any string even an empty. Question mark means any character. If asterisk or question mark are not meant as wildcards but characters appearing in the value, they must be escaped with a backslash () like this: *, ?. Also if backslash is meant as a character appearing in the value it must be escaped like this: \.
Right of the client, role and user field is a button with a question mark (?). By clicking the button defined clients, roles or users can be selected and filled into the fields from a list in a popup window. The user field has moreover right of the button with the question mark two further buttons: plus (+) and minus (-) which allow adding further or delete user patterns in the chapter row. Only those chapters can appear in the generated documentation where the user name of the current user is matching at least one of the specified user patterns.
By clicking the plus (+) or minus (-) control element at the beginning of each chapter row the multiline text field for editing of the chapter text is being displayed or hidden. The text specified in this text field is displayed as the content of the chapter in the generated document.
A global definition can be edited by selecting it in the global definitions list form (checking the check-box at the beginning of the table row) and clicking the Edit button in the global definitions list form. Alternatively a global definition can be edited also by clicking on the name in the table of the global definitions list form. After that a form with the global definition fields appears. This form is the same like the form for a new global definition except, that the field Client is read-only and cannot be changed.
An existing global definition can be used as a base for a new one by selecting it in the global definitions list form (checking the check-box at the beginning of the table row) and clicking the Copy button in the global definitions list form. After that the form for a new global definition prefilled with the settings from the selected global definition appears. Beware that at least the global definition name must be changed before the new global definition can be created.
One or more global definitions can be deleted by selecting them in the global definitions list form (checking the check-box at the beginning of the table rows) and clicking the Delete button in the global definitions list form. Beware that by deleting of a global definition also all process definitions using this global definition are deleted. Beware that only global definitions which are not in use by existing processes can be deleted. An alternative to the deleting of a global definition is to disable it.
Select one or more global definitions from the global definitions list form (checking the check-button at the beginning of the table rows) and click the Into Transfer Case button in the global definitions list form. After the selected global definitions have been added into the Transfer Case you can add another global definitions or another objects into the Transfer Case or continue with other administration work. For more information about the Transfer Case see the description of the Transfer Case tool in this document.
regexmatch(string, string) or strregexmatch(string, string) – Returns true if the string in the second parameter matches the regular expression in the first parameter, or false otherwise. For example if the specified regular expression looks like this '[a-zA-Z][a-zA-Z0-9]*', the function checks whether the string in the second parameter starts with a letter and is followed by arbitrarily long sequence of alpha-numeric characters. For more information about the syntax of the regular expressions see (thereby beware that the function adds automatically '/^' at the beginning and '$/u' at the end of the regular expression specified in the first parameter).
