Task

Workflow

Pool

Filter

Dynamic field

Workplace

Archive

User (implementers role)

Customer (authority role)

Author

Administration part

Administrator of the system

Notification

Module of Helpdesk and helpdesk user (customer)

Roles in TaskPool system

NOTE: The Observer on the submitter's side can only see records belonging to this side, hidden comments of submitters, time records, etc. Similar situation is on implementors side.

There are also functions Co-implementer and Co-submitter. Co-implementers and co-submitters have the possibility to add comentaries into the tasks and get the notifications from them. Their allocation to the task is described in the user's manual. Co-submitters could be given full rights as the implementer's, see chapter 3.3 Access limits.

The following table describes complete rights of the individual roles, where:

and on:

- the role has the right to do the given activity

- the role has no right to do the given activity

- the role can have right to do the given activity in depends on the settings in the pool administration on the card "Workflow" (more in the chapter 3.2 Workflow)

Table 1.1. The rights of the individual roles

Activity	MS	S	Os	SM	I	Oi
viewing the tasks
Entering the tasks
entering the autotask
take over the task
task assignment to the implementer
task commenting
task completing
task controlling
task confirmation
task deactivation

NOTE: When viewing the tasks, it is possible to set each of the roles to only see their own tasks. This is done in the pool administration on card "Access restrictions" (chapter 3.3. Access restrictions).

You can get into the administrator's section via button "Administration". For the TaskPool administration you will use the bookmarks in the administrator's section (Escalation, Fields, Filters, Pools, Users, Licence key, Customer settings, Templates, Files, POP3 mapping, Notification, SLA, E-mail reports, Authentication, Knowledgebase, User dynamic fields, External Database Manager, SMS, Cost evidence, Autotask).

Figure 1.1. Administrator's section

For coming back you will use the button "Workplace".

When you click on the icon New the form will appear for a new user creation in the system. Only the administrator can create new user, after that, each user can edit all settings themselves.

Figure 2.1. New user creation

Username and password are the standard resources for login to the system. First name and the last name will appear in every record of a change being made to the system by that user. Notifications about changes in the tasks that concern the given user will be sent to the specified email. Field for telephone number is only informative. Default language, in which to login to the system can be selected for each user.

Permanent login will only work if this field is checked in the users profile. At the same time you can set, for how long will the login be valid.

With the button Show time records we turn on the display the so-called "timesheets", more in the chapter 21. Cost evidence.

In the field Status we can set, if the user will be active or inactive, in second case the user will be denied access to the system and will not receive notifications. We use this choice in case, when the users action in the system TaskPool becomes meaningless. The user cannot be removed due to already established links, all changes and entries made by the user before deactivation will remain in the system. The inactive users also do not count towards the licence.

The last choice is if the given user will be synchronized with LDAP. More about LDAP in the chapter 10. LDAP.

We can edit the created user via clicking on the name from the list of the users at the card "Users" in the administrator's section. The window will appear as if you create the new user with the difference that there are two more options of setting. They are "Notifications by pools" and "Membership in pools".

On the card "General" we set the basic features of the pool. Already created pool cannot be deleted, but deactivated. The reason is obvious, there might be some relations to the other part of the system. Closed pool is not therefore counted to the licence.

Figure 3.1. New pool creation: General

A field Category is not obligatory tab. It can associate each pool with similar purpose (e.g. Helpdesks) and serve better handling with the pools thanks to the filters. See more in the chapter 7. Filters.

The pool color will mark each task with a specific color in the workplace and in the detail of the task. It enables more intuitive work with tasks, for e.g. all helpdesk tasks are yellow etc.

Figure 3.2. Pool color

In case of using pool Logo , it is displayed in the workplace on the left side of the top bar.

On this card the process of task implementing in the given pool is defined.

Figure 3.3. Creation new pool: Workflow

The following options determine the rights of each role in a particular pool. The following is a description of more complex settings:

Number of days until deadline is default setting of the deadline for the new task in the given pool, i.e. number of days necessary for completing the task. The time could be changed by SLA, if it is set. See more in the chapter 18. SLA.

Automatic archiving means, that complete tasks (they have a green icon of the exlamation mark) will be put automatically into the archive after two days.

Move of tasks is an option thanks to which we can move tasks from the given pool into the other one. Moved task will be put into the archive of the mother pool in the status "Moved" and there will be written a new link to the moved task. There will remain all the values and history of the moved task and it will be created in the status "Assigned to implementation". Moving is suitable to use if the task was created by mistake in the different pool. If you know this would not appear, we recommend switching this configuration off. The form for task editting will be simplier.

ATTENTION! If we move the task to the pool, which does not contain the same data item (e.g. dynamic fields) as the original pool, the moved task may lose data.

Export / Import of tasks. If set in the system linking two or more instances of systems with each other is possible with these options turn on pools where events will be offered Export and pools, which will be offered as target in the linked instance. Transferring to the imported task history of the exported task. The amount of information transmitted depends on the configuration of the target pool.

Selecting Assigning Tasks changes the assignments of implementer and co-implementers.

If the task is Assigned by Service Manager, the implementer cannot take it over himself. Otherwise, the implementers themselves take over tasks without the need for assignment.

Implementer confirms assignment allows the implementer to confirm the assigned task. You can accept or reject the assigned task.

Implementer can assign own tasks means the ability to assign his task to the implementer to other implementers. If the option is not checked, only the Service Manager has this permission.

Ability to assign the creating task extends the form of a new task with the ability to assign implementer or co-implementers (depending on the role display matrix in Access restrictions). The service manager has always this option enabled.

Swithing on the string Service manager approves implementation we determine that the task can be taken over by the director after approving of the task implementation by the service manager. At the scheme there is the string shown with a red colour. Similar is the string Manager of submitters allows implementation.

By the string Agreement to conditions we can set the right to the deadline and price endorsement. If the right will be given only to e.g. service manager, other users can only submit a change to the conditions and the service manager must approve them or decline them.

Service manager checks tasks means that after completing the task by the implementer, the task will continue to the service manager who will check the implementation and then he/she can confirm the task or give it back to the revision. The task will not be fiinished until it is checked. Therefore it cannot be put into the archive without its confirmation. At the scheme there is a string shown by a yellow colour. Similar is the string Submitter confirms tasks. It is shown by a green colour. If both strings are switched, task finished by the implementer goes first to the service manager check and then to submitter's confirmation.

If it is active Use invoice loop, tasks will remain in the pool after completing, or check, until the service manager marks it as "Invoiced". At the scheme below there is a string shown by a violet colour.

Implementer confirms assignment means that the service manager submits the new task to the implementer only and he/she has an option to accept the task or decline it. At the scheme below there is a string shown by an orange colour.

Information supplied by customer comment - if the task is in the Waiting for information state and the customer adds a comment (either from the customer interface or from the e-mail), the task switches to the previous state.

At the bottom of the screen there could be rights set for an editing option, price display and deadline to each roles in each task status.

Here you can see the scheme how workflow can go through.

Figure 3.4. Scheme of workflow

If there are a lot of submitters and implementers, it is essential to administrate tasks display and notifications sendings. At this card it is possible to set which tasks will be accesible to which submitters and implementers and whom the notifications will be sent to. Each submitter, or implementer can see all tasks and get the notifications or see all the tasks and get notifications only from their own tasks. The last option is that each submitter or implementer can see only their tasks and get the notifications from them.

You will get the simplier pool to each submitters/implementers.

Figure 3.5. Creation of a new pool: Access restrictions

In the section Display of the users' list the rights are set, which role sees which role in the arbitrary list of users. This list can be found e.g. when assigning the task to the implementer etc. It is set as a default that all users see all of the given pool, we recommend keeping this setting.

In the section Hidden commentary we can set, which roles have the right to create the hidden commentaries to the tasks. Generally a hidden comment of someone from the agents side (implementer, service manager) is not seen by the submitters side (submitter, manager of the subbmiters) and so the other way. It is possible to allow that the commentary will be at every task hidden by default. This can prevent the possible leakage of internal information.

Option to send urgent notifications means that the given role will have checkbox at the bottom part "Urgent". If the checkbox is ticked, all the users of the pool will recieve the notifications with the status "URGENT !!!". This option is there because some of the users cannot recognise the difference between the urgent and less important notifications, therefore it is an option not to allow these notifications to be sent.

If the option will be switched off Display the submitter the second and other assignement, the submitter of the task will see only the first assignement to the implementer in the history. If the task is assigned to the other implementer, then this tab will not be seen in the history. If the option is active, then the submitter will see all the assignements for the whole cycle of the task.

Next option is Co-submitter overtakes the implementer's rights. If this checkbox is switched on, the co-submitter has the same rights as the task implementer. If it is switched off, the co-submitter can only add some commentaries to the task and receives the notifications from it.

The next is option to activate External submitters. For each task, it activates a field where you can list e-mails separated by a comma, on which they will be customer notifications are sent (as well as to the external task submitter).

Another option allows you to send eitherDefault external submitters notifications (according to the helpdesk settings), or a custom notification defined in the tab Notification.

The users are created and editted at the TaskPool level. The roles are assigned to the users by the administrator at the pool level. In each pool it is possible to define accessible number of the users (according to the licence). Each user can be given one of six roles in the particular pool. Each pool must consist of at least one service manager.

Figure 3.6. Creating a new pool: Roles

At the end of each user there is [A] or [N], which corresponds with the status active or inactive. In the list of not assigned users there are active users displayed. By ticking teh field Show inactive users the list will be added by these too. If there is "Not assigned" in the field, the users are not displayed, it is necessary to create them first. (see the chapter 2. Users).

You can label only one or more users in the left field and thanks to the arrow ">>" you can assign these users to the given role. Similarly it is possible to move vice versa. A change in the roles is possible to be made anytime during the pool existence, as well as the other setting of the pool features.

Notifications are e-mail notices to the users about the changes in TaskPool. At the card "Notification - timing" we can set timing of the e-mail sendings. Also we can set adress of the submitter and which format there will be for the subject of the notification.

Figure 3.7. Creating a new pool: Notification - timing

Note: Notifications can be send except e-mails also via SMS, see more in the chapter 22. SMS.

Delivery of notifications will be

In this section we set timing of the notification itself. An option Always garants that notification will be sent straight away when the task is changed. Sometimes it is annoying and therefore it is possible to set a period of the sending and the time from and to the notifications will be sent. We can set e.g. sending the notifications from 8:00 to 17:00 with a period of one hour. This overall e-mail then will consists of the notifications from all the tasks, which were changed during the last hour. If we select Never, the notifications from the pool will be never delivered. The exception is the urgent notification. If the field "Urgent" is ticked during the task editting, the notification will be sent to all pool members.

Subject of notification

TaskPool enables subject configuration of the notification e-mails. It is possible to set a different subject of the notification for each pool separately. It can be used for e.g. better filtration of the incoming emails.

Note: This setting is not related to the periodical notifications, whose format of the subject is fixed.

At the configuration of the sample for the subject of the notification you can use these placeholder's strings:

Submitter of the notifications

According to the field in the e-mail "From" can the notifications be easily sorted in the post into the tabs, according to the pool they were sent from.

Notifications according to users

This option enables to set each user of the pool a unique timing of the notifications. Button "Notification according to users" will be shown when editing already created pool (it is not possible to edit it when a new pool creation because there are not any users put yet). It is at the bottom on the bar next to the buttons "Save" and "Close the window".

Figure 3.8. Notifications according to users

In the selection field on the top it is possible to select a particular user and then change the setting for him/her:

On this card it is possible to set number of priority levels used by the given pool (e.g. from 1 to 4) and also the names of each priority in the supported languages (Critical, High, Medium, Low etc.). You can also determine which priority will be a default during the task creation.

Then it is possible to set, if the priority will be shown as ID (the number 1-4), or as Label (the name set of the priority level). It is possible to set for a detailed display and list of the tasks separately.

At the bottom part of the form the right to see the priority of the task according to the roles is possible to set (column "Display") and then the right to change the priority of the tasks according to the roles and tasks status (other columns).

Figure 3.9. Creating a new pool: Priority

When configuring in the image, all roles see the priority, while Manager of submitters and Submitter can determine the priority only when creating task and Service manager can change the priority when creating and in the conditions Entered, Taken over, Proposed for allocation and New conditions.

On this card it is possible to set, which SLA schemes will be used for a given pool and which will be a default one. Setting the rights for a change and SLA display and also for manual update time setting is similar to the settings of the priorities or the dynamic fields. More about SLA schemes configuration see in the chapter 18. SLA.

Figure 3.10. Creating a new pool: SLA schemes

On this card it is possible to set, which dynamic fields will be displayed in the pool and which roles they will be displayed to. Dynamic fields from the global list of the created fields are assigned to each pool. See more in the chapter 4. Dynamic fields.

Figure 3.11. Creating a new pool: Fields

At the fields, which we would like to enter into the pools, is neccessary to tick checkbox "Show field" and create a value "Order", according to which fields in the task will be displayed below each other. As an order the different positive numbers. The field with the lowest number will be above. We recommend fields numbers e.g. 10, 20, 30 etc. because of the possibility to add fields between those which already exist, then you can use numbers e.g. 1, 2, 3 for them, otherwise it will not be possible.

Rights to see and edit the fields is possible to set similarly to settings priorities after clicking the link "Edit access rights". Each role is possible to be set exactly connected to the status of the task where these roles will have an option to be edited.

On this card there are not any information displayed normally. If TaskPool is synchronized with a different system (MarkTime, COBS), there will be configured a setting of synchronization. TaskPool synchronization with the other system is quite complicated for a standard user, therefore we recommend consulting it with ComArr stuff.

Taskpool enables to set choosing e-mail box and transform them to tasks. Then the users of TaskPool as well as helpdesk users create the tasks or add commentaries just via e-mail sending to the given e-mail address.

Description of e-mail interface

For the e-mail recipients' requirements is used protocol IMAP, POP3 or Gmail API, known mainly from the e-mail clients, which is used for downloading e-mails to the computer. The princip is similar here, but e-mails are entered into the TaskPool as a new task. This setting is for each pool separately. It is clear, which pool the tasks will be entered to.

For receiving e-mails it is necessary to change the state active and fill in the configuration tabs.

Figure 3.12. E-mail Interface (IMAP)

Using the button Verify login we will verify if logging successful or not, thanks to the small window that will pop up.

Figure 3.13. E-mail Interface (Verifying login)

• Server URL: IMAP or POP3 mail server address (eg: imap.seznam.cz)

• Login name: usually e-mail (for example taskpool@seznam.cz); in the case of Office 365 it can also be used for a shared mailbox (for example e-mail@company.com/shared_e-mail@company.com)

• Password: e-mail password

• Use TLS: in most cases, the connection requires authentication to be turned on

• Save as EML: the entire e-mail in EML format is saved as a task attachment

• Delete mail on server: Never - the e-mail remains after reading in the mailbox; Always - after reading, the e-mail will be deleted; Parsed - only e-mails transferred to the Taskpool will be deleted, the others will be kept in the mailbox

• Created date from email: the time of creating the task will be the time of receiving the e-mail; otherwise, the e-mail read time will be recorded

• Ignore by expression: you can enter expressions in the field, the occurrence of which will prevent the e-mail from being downloaded to the TaskPool

Figure 3.14. E-mail Interface (Google API - method Oauth2)

• Client ID a Client Secret: these values are defined in the Google / Google Workspace account settings. Users of production server taskpool.net it is not necessary to set these values, a connection is already defined for them. Users of the on-premise solution must create this verification for your gmail account ( https://console.cloud.google.com).

• Login: e-mail from which tasks will be retrieved.

At the moment, when the e-mail will arrive to the given address after activating the function, TaskPool creates a new task of it in the given pool. Subject of the e-mail is understand as the subject of the task, text of the e-mail is saved into the task description. Deadline will be set by default for a given pool. If the implementer of TaskPool will answer to this e-mail, the answer will arrive to the original sender (submitter) onto his/her e-mail. If he/she answers again to the e-mail, reaction will be written as a commentary to the existing task. Submitter does not need to know that there is TaskPool on the way.

Firstly you need to fill the Type, where you will choose from the menu OAuth2 Imap, after that you will fill the login name, URL and from Azure you need to add data to Client ID a Client secret (More in Setting OAuth 2.0 for TP). Then you need to save the data and close the window.

Figure 3.15. Login to Microsoft Azure

Again you will open Email Interface and there will be newly displayed Login/Logout.

Figure 3.16. Login/Logout

By clicking on Login you will be redirected to the Microsoft page, where the rights are approved.

Figure 3.17. Redirect to Microsoft page

Submit, and if everything went well, it has to show up Okey.

Figure 3.18. Required permissions

Go back to Email Interface and by Key F5 refresh the page. The filled fields shoul appear date, acces token a refresh token. The data needs to be saved again and close the window.

We can check the login using the button Verify login (More in Description of e-mail interface).

Enter the web page in your browser (https://aad.portal.azure.com/).

Login to the user, which has authorization to manage Microsoft Azure (account Microsoft 365 with role Global administrator or user with permission to change Application registration).

Figure 3.19. Login to Microsoft Azure

Choose from left column item Azure Active Directory and then Application registration.

Figure 3.20. Microsoft Azure

Choose the option New registration.

Figure 3.21. New registration

Fill name Taskpool and as identificator fill in the URL adress of your application TaskPool.

Example: https://firma.taskpool.cz/oAuth2LoginCallback

Figure 3.22. New registration - fill in data

Then choose from left menu Verifying and below fill in the URL adress for logout and check option Tokeny ID (used for implicitn and hybrid tokes) and save.

Example: https://firma.taskpool.cz/index.do

Figure 3.23. Verifying

Choose the menu Certificates and secret codes, choose Clients new secret code and fill in Description and choose validity 24 months.

Figure 3.24. Certificates and secret codes

Generated code Value copy and paste to TaskPool as item Client secret.

Figure 3.25. Clients secret codes

Choose Overview and copy the value ID aplications (clients) and paste to Taskpool as item Client ID.

Figure 3.26. Overview

Furthermore you must choose Business applications and pane Consent and authorization.

Figure 3.27. Business applications

And check, if it is chosen option Allow user permission for applications.

Figure 3.28. Setting up the users consent

On this card there are also sets of the rights for each group of time records. More about the time records configuration in the chapter 21. Cost evidence.

Figure 3.29. Creating a new pool: Cost evidence

For each role we can assign one group of activity. In our case the service managers were assigned the group of activity Customer support and the implementers were assigned a group Development. When time record creation, each role will see all activities from the given activities and it will be possible to write into them.

In the other part of the screen there are settings of display options. They are these:

Format of the records editing might be the following:

Then it is set which roles will have the record displayed of all time to the given task.

The scheduling function serves for a clear record of the timetable of individual tasks. The solution of each bag can be planned for any date or time period. The scheduled pocket scheme can then be imported into calendaring software, tested with Microsoft Outlook 2007 and 2010 and Mozilla Lightning, Apple iCal and Google Calendar.

Figure 3.30. Scheduling

Planning rights are set in the same way as for dynamic fields, so the planning right can be assigned eg only to the solving side, etc. It is also possible to set in which states this field will be mandatory. In the editing of the pocket, the next two items are displayed to the authorized roles, in which the scheduling dates are filled.

Figure 3.31. Scheduling by task edit

In case of active dialing se value "deadline" if other dates are empty there is no need to fill in individual dates. If at least one field is blank, TaskPool automatically substitutes a deadline value. For better control of bag planning, however, we recommend that you disable this option.

On this tab, it is possible to specify the possibilities of links between individual tasks. Binding of tasks is described in the user manual in chapter 6. Linking tasks.

Figure 3.32. Linking tasks

Free linking of tasks allows individual roles to create ties in a particular pool to any other pool to which they have access. Thus, they can create new parent tasks, sbutasks and links to a given task, or bind these tasks to other existing tiles.

Copy submitter - use this option to copy the original task submitter to the target pool (if the target pool configuration allows it).

Notify parent task after finished - if this option is checked, a comment will be inserted in the parent task when the subtask is ended (finished, deactivated, moved or exported). If the last subtask is ended, it reports All Subtasks ended.

In this tab, you can also set buttons to simplify link creation. The button predefines which link and to which pool it will be created. In the Edit Bag window, these buttons will appear below the comment window, and when you click on them, the form for creating a new bag will automatically appear in the preset pool.

The Add Link window may look like this:

Figure 3.33. Task linking

If the user (role) has the right to freely link the tasks, it is accessible by clicking on the link below the buttons.

Configuration of each pool is possible to copy. Only configuration is copied, tasks created in the given pool are not copied. The copying is possible to be done by clicking the button "Copy Pool" in the list of the pools. The form will appear after a new pool creation with the difference that the whole configuration including the name will be the same as the copied pool configuration. We recommend changing the name of the pool and then click the button "Save". In the list of pools there will be a new pool with the same configuration. It is possible to copy Helpdesks in a similar way, see the chapter 16.16 Helpdesk copying.

On this card it is possible to add new tags. On the left click on "New", where you set a name and color of the tags. Then click "Save" and "Close window".

Figure 3.34. Card tags

Move to card Pools, where you can click on the task name.

Figure 3.35. Card Pools (Tags)

In task editing click on card Tags and check them. Then click "Save" and "Close window".

Figure 3.36. Tags - task editing

In task click on "Edit". In the right column you can filter or choose unlimited number of tags from the menu. Save it again and the change will appear in the comments.

Figure 3.37. Task editing - Tags

Figure 3.38. Tags - comments

In the task overview you can see set tags, which are color-coded.

Figure 3.39. Tags - Task overview

In the users files is possible to search or filter files using the name of the file or suffix (.png).

Figure 3.40. Card Files

Dynamic fields enables to define arbitrary additional data structures. They are possible to be created in the administration of TaskPool and assigned to each pool.

Figure 4.1. Examples of dynamic fields

Dynamic fields actually represents the other features of the task and they are possible to be used for saving different values in the task or e.g. in combination with filters for task changes according to these values. Dynamic fields also enables to display data from the external databases in the task.

Creation and editting of the dynamic fields is on the card "Field" in the administrator's section. Creating is done by a button "New" and editting by clicking onto the name of the existing field.

In the form for a new field creation we firstly select a type of the dynamic field, identificator (it is a name, which identifies possitively the field - a unique for each one), then the name of the field according to the languages and default field value. Default value will be displayed until the first adjustment of the field, e.g. at the text fields it is preselected text.

At the field "OnChange" is possible to write arbitrary javascript. There could be more these scripts; they are divided by a semicolon (";"). These scrips are always automatically implemented after the field loads. We can create e.g. dependences between the fields. This is described and set in the demo configurations, which our staff will show you if requested.

These features have all fields in common. Other features differ due to the type of the field and they will be described in the following chapters.

This field is for writing an arbitrary text into one line. After the selection the type of the field, the general features, size of the font and maximal number of the characters, can be assigned, all in numbers.

Figure 4.2. Dynamic field creation, type Text field

In reality the field looks like this one:

Figure 4.3. Dynamic field Textfield in reality

Dynamic field Textarea is similar to Textfield, but with a difference in a possibility to write a text onto more lines. We can set a number of lines and their width during the creation.

These two types have a similar setting, only display is different. We select the type of the field and create options of the selection except the general features. We create these options on the card "Options" in the field edit.

In the field "Default value" we insert an ID of the default option.

Figure 4.4. Creation of the field's options Selectbox and Radiobutton

The Selectbox field has a whisper that makes it easier to find the record you're looking for.

Figure 4.5. Dynamic field Selectbox

Figure 4.6. Dynamic field Radiobutton in reality

Note: Functions of the cards "Transition" and "Workflow" in the Selectbox settings are described in the chapter 5. Dynamic fields extension.

Dynamic field Multi Selectbox works similar as klasic Selectbox, but it allows you to select several options at once.

Figure 4.7. Dynamic field Multi Selectbox in reality

This type of the field is a checkbox. Except general features, this field does not have any other setting options.

Figure 4.8. Dynamic field Checkbox in reality

The field type Number is similar to Textfield with a difference in keeping only the numerical value. TaskPool controls the entrance values and do not allow the difference from the numerical ones. For the decimals the point is used in the field (in the field is then e.g. 10.564, at the integers it is 10.0).

This type is presented by a counter. The value insterted into this field do not replace the original value when task modification, but it is added. It means when we write into the type Counter with value 20 value 5 after modification, then after saving, the value will be 25 in this field. Each modification of the field is written in the task history.

Value of this field can be decimal (e.g. 15.27), and TaskPool uses the point in the field Number.

This field is suitable for e.g. number of kilometres. We do not recommend using the field for worked out hours, there is a special function in TaskPool implemented, see more in the chapter 21. Cost evidence.

As the name shows, the values of date, time, actually values of date and time equally, can be kept in these fields. The expanded options can be used for categorization e.g. in filters we can search specific time periods. We can use standard arithmetical operators (<, >, =).

Tabs are inserted in format:

For the dates inserting the IMHO calendars can be used.

Figure 4.9. Dynamic fied DateTime in reality

For configuration of this field the basic knowledge of SQL language and Javascript is essential. If you do not have this knowledge, we recommend consulting this configuration with ComArr stuff.

SQL selectbox is a field, where it enables to use external database. We use it e.g. when we want to use selectbox with a big amount of otpions, which are saved in the external database or for creation gradually depended fields. We avoid the configuration of each option seperately into the classical selectbox. It can be a selection of a type of device, workplaces etc. Number of options is flexible because it does not work with statistical options, but with SQL requirements.

The creation is correctly configurated authentication for SWL selectbox. In this authentication the database is determined, which will be used for option selection SQL selectbox (more about authentication in the chapter 17. Authentication).

As at the classical Selectbox we can choose the AutoComplete usage. The AutoComplete is suitable when we have a big amount of options.

LoadDependentOptionsByHdUsername('CSlocation')

LoadDependentOptions('CSdevice', this.value)

LoadDfValuesFromDb('3','SELECT z.sn as CSsn, z.pn as CSpn,
   p.name as CSproject, z.id_tp_sla as sla_schema FROM device z
   JOIN project p ON(z.id_project = p.id)
   WHERE z.id = \':fieldValue\'', this.value)

Basic SQL

Only SQL orders for option selection are set on the card "Options".

A selection "Connection to database" can offer all configurated authentications. The selected authentication will be used for option SQL selectbox selections.

Figure 4.10. Setting SQL selectbox

Basic SQL returns a list of values which should be insterted into SQL seletbox after page authentication.

Example 1)

SELECT l.id as optionIdent, l.name as label FROM location l
   WHERE l.id = 0

...returns a list of all locations, where id = 0.

Example 2)

SELECT 0 optionIdent, '' as label, '' as shortcut

...tops us the empty values into the selectbox.

(SELECT 0 as optionIdent,'' as label, '' as shortcut)
   UNION SELECT l.id as optionIdent, l.name as label
   FROM location l LEFT JOIN user at
   ON (u.id_customer = l.id_customer)
   WHERE l.active = 1 AND u.login = '?'

(SELECT 0 as optionIdent,'' as label, '' as shortcut)
   UNION SELECT id as optionIdent, tag as label FROM device
   WHERE id_location = '?' AND active = 1 ORDER BY label

SELECT l.id as optionIdent, l.name as label
   FROM location l WHERE l.id = '?'

SELECT l.id as optionIdent, l.name as label FROM location l

SQL basic: SELECT 0 optionIdent, '?' as label
   UNION SELECT k.ID as optionIdent, k.category as label
   FROM category k WHERE k.active = 1
SQL dependent: (empty)
SQL options: SELECT k.ID as optionIdent, k.category as label
   FROM category k WHERE k.ID = '?'
SQL all: SELECT k.ID as optionIdent, k.category as label
   FROM category k
Default value: 0

SQL basic: SELECT 0 optionIdent, '?' as label
SQL dependet: SELECT 0 optionIdent, '' as label UNION SELECT pk.ID as
   optionIdent, pk.subcategory as label FROM subcategory pk
   WHERE pk.category = '?' and pk.active = 1
SQL options: SELECT pk.ID as optionIdent, pk.subcategory as label
   FROM subcategory pk WHERE pk.ID = '?'
SQL all: SELECT pk.ID as optionIdent, pk.subcategory as label
   FROM subcategory pk
Default value: 0

SQL basic: SELECT 0 optionIdent, '?' as label
SQL dependet: SELECT l.ID as optionIdent, l.location as label
   FROM location l join users u on (u.location = l.ID)
   and u.username = '?' and l.active = 1
SQL options: SELECT l.ID as optionIdent, l.location as label
   FROM location l WHERE l.ID = '?'
SQL all: SELECT l.ID as optionIdent, l.location as label
   FROM location l

In addition to attachments that can be added to comments, you can create and display a specific attachment type and display it directly between dynamic poly. Examples are Offer, Contract, Invoice, Protocol and other types of attachments. This attachment can be overwritten new file and keep it up to date. The history of changes is recorded in the history in the task detail.

Figure 4.11. Dynamic field Protocol (file)

A text field whose content is visually hidden from the author and other users (replaces * with characters).

A text field with a link to URL, FTP, mail-to, etc. protocols can be displayed. URL link opens in new browser tab.

Signature field, where a signature can be entered by mouse or by touch on the touch screen. At the profile we click on Administration and choose card Field. Add "New", fill in data and save.

Figure 4.12. New field Signature

We click on card Pools a search for task and open it. In the card Pools we find the signature, check it and using "Adjust access restrictions", set other parameters, then save.

Figure 4.13. Check field Signature

In task detail click on "Edit" and in right column down write the signature to the signature field, which can be removed by the cross. Save it and the changes will be visible in task history and signature will be seen in right column down.

Figure 4.14. Completed signature

Html field, where you can enter a link that will be displayed and clickable.

Figure 4.15. New field Html

Click on card Pools and search for task, open it. In card Field then find html, check it and by "Edit access restrictions" set next parameters. Then save it.

Figure 4.16. Check field Html

In task detail click on "Edit" and in right column down into the html field paste the link, which can reach the page. Save and changes will be seen in task history and html will be seen in the right column down.

Figure 4.17. Completed Html

Value of type Selectbox for the task can be changed automatically according to the change of the state of the task (automatic or done by the user).

For each dynamic field of the type Selectbox it is possible to define the condition thanks to a triple of values, while completing the change of the dynamic field will appear. This triple of values consists of:

For a successful action the two conditions must be completed (change of the state to the end state of the workflow and initial value of the dynamic field).

Conditions are defined thanks to the selections of possible values of selectbox and are independet on the users' roles in the pool and the actual workflow of the pool. If the user has no right to change the value of the dynamic field and will make a change in the workflow (e.g. completes the task), dynamic field will remain without a change. About the changes of workflow and values of the dynamic fields the users are announced by notifications and these changes are recorded in the task history.

Figure 5.1. Change in the value of the dynamic field in relation to the state of the workflow

For the example in the picture: If anyone in the pool (who has the right to change the value of this dynamic field) completes the task and at the same time there will be the value of this Selectbox Ordered, then the value of the field will be automatically changed into Accepted. It is similar when task takeover.

For each dynamic field of the type Selectbox it is possible to define a condition thanks to duo of the values, while completing the change of the taks' state will be done. Duo is:

Conditions will be defined thanks to the selection of the optional values from the given selectbox. Conditions are independet on the users' roles in the pool and the actual workflow set in the pool. If the user does not have a right to change the workflow and will change the dynamic field, the workflow will remain without changes.

Figure 5.2. Change of the task's state according to the change of the dynamic field

About the Workflow and the dynamic fieds changes the users are announced by notifications and these changes are recorded in the task history.

TaskPool consists of the status, which is not possible to enter automatically, because other parameters are necessary for the state's change.

Status, which is not possible to enter automatically:

Conflicting situation and its solution

During the task implementation there could appear so called conflicting situations. These situations appear when the workflow should be changed into the state which is not possible in the given pool. For example, in the given pool it might not be possible to select the state Confirmed, but there might be a rule which requires this change. These situations are then implemented according to the following key:

Note: rule A) counts, when there is not any other state in the workflow, rule B) counts, when in the workflow there is another state before archiving.

Conflicts flowing from the different roles position

The other conflicts might appear, caused by the differences in power of each role, e.g. submitter cannot assign the task. These conflicts are implemented by a following way (number labelling of the task status described in the chapter 7.2. Filters definition):

It is possible to precede these conflicts by setting the rights for editing of the dynamic fields in each state. They are set in the configuration of the pool on the card "Field" (see the chapter 3.8. Field). Submitter is not allowed then to edit the field until the task is assigned.

Other extension is Transition limitation among the values of the dynamic fields. It means that the value of the dynamic field can be dependent on the previous value. In reality we can determine which values can be changed to the present value and which ones not. These limitations are independet on the users' roles and workflow of the given pool.

Configuration of the transition limitation can be done for each combination of the previous and the new values of the field thanks to a matrix of checkboxes. Lines of the matrix mean the previous value of the dynamic field, columns then describe the target value. If the field is ticked, the change of the field will be allowed. On the other side the transition will be prevented.

Figure 5.3. Transitions limitation among the values of the dynamic fields

In the example in the picture it is possible to transit among each value of the field only "ascending". If I change the field onto the option "two", come back to "one" and "?" will not be possible.

If it is possible, configure the field so that the conflits will not appear. In most of the cases it is possible to do so. The best alternative is to prevent the conflict appearance using the settings of the rights for the dynamic field editing. (see the chapter 3.8. Field).

If the conflicts appears anyway, conditions are evaluated in the following order.

Other collision can appear, when more fields are changed and these changes can cause more changes in the state of the task. We strongly recommend using only one field for the state changes.

The so-called Absence Module is an extension of dynamic user fields. This is functionality allowing each user to define the period when he will not be available. TaskPool then not allow the allocation of absentee users..

The absence module is configured in the administration at the bottom of the "Dynamic user fields" tab.

Figure 6.4. Dynamic user fields: Absence module

For correct functionality of this module it is necessary to have defined two dynamic type fields Date or DateTime. One is then used as a field to enter the beginning of the absence and the other to enter its end. In our example, we have configured two Date fields with labels "Holiday from" and "Holiday to" (the order is governed by the identifier of the relevant dynamic field. After clicking the button Save the absence module field appears in the user profile editing.

Figure 6.5. Setting the absence time

The time of absence can be defined by each user and the administrator has the right define the absence time for all system users.

Escalation and filters related to the absence of users shall be generated using conditions for dynamic fields of users, help can be found under the escalation / filters edit form in "To" and "Dynamic Fields" sections. More about filters in chapter 7. Filtersand about escalations in chapter 8. Escalations. Here we show some sample settings for working with the absence module.

It is a definition, about the tasks which should be displayed in the workplace. This definition can be used within one pool or more pools. Each filter has its own name. Using the filter is then easy - the user can switch between the filters, which he/she access, thanks to the selectbox for the filter selection at the workplace. Into the selection then it can be put default filters of the pool and also defined filters by the user or the administrator.

Pool

Filter defined by the administrator

Filter defined by the user

Creation and edition of the users' filters is possible in the user's section using the button "Other actions -> Filters". The list of "My filters" will be displayed, i.e. filters, which the user has the access to.

Entire access to the list of filters (default filters of the pool, administrator's filters, users' filters) and their editing is enabled in the administration section on the card "Filters".

Figure 7.1. Administration: Filters

A new filter can be created by clicking "New", editing the existing one can be opened by clicking the given filter.

System filter (defined by TaskPool)

The system filter is automatically generated by TaskPool system when a new pool creation and it displays all the tasks, which are covered in this pool (of course the access limitations in the pool setting are respected). In the list of filters you can find systemic filters in the section "Filters of the active pools" and "Filters of the closed pools".

Systemic filter is not possible to edit by the user or the administrator. The administrator has only the possibility to set the rights for the access to this filter and after clicking Users at the filter. The rights are set thanks to the checkboxes "Access" and "Visible".

In the top left corner of the form is the textfield visible "Mark user from the Pool ID". We can write the ID into it and after clicking the Mark, system will mark all users who have the membership in this pool.

Figure 7.2. Administration: Rights for the filters display

Filter is defined thanks to the form for creation or editing the filter. We open it by clicking the button "New" or onto the name of the existing filter. Help and the list of the used strings to any sections can be opened below the form by clicking one of the butons Sort | Conditions | etc.

Figure 7.3. Definition of the filter

An option Sorting the system determines tasks display of the given filter. We recommend writing the option "DEFAULT", sorting the tasks then remains the same as in the default filters of the pools. Sorted can be also e.g. according to the ID of the task and its other features, you can see more by clicking Help "Sorting".

If you do not tick the field Distinguish archived/not-archived tasks, the active tasks, archivated tasks as well as deactivated tasks will be put there.

Information displayed in the list of the tasks is the setting, which will appear at the tasks on the workplace in the field "Commentary". See more in the chapter 3.3. Access limits.

The Conditions are the most important when filter definition. They determine which tasks will be displayed by which filter. To the definition of the conditions is possible to use nearly all the tasks' features and thanks to logical operators "&" (AND) and "|" (OR) the conditions are possible to be combined. See more by clicking Help "Conditions". Features for filtering the tasks can be found in Help "Task features".

List of all ID status, pools, users, dynamic fields and others is displayed in Help "Actual values".

Syntax for conditions settings is object.features. The subject can be the feature or the dynamic field. If we come back to the picture of filter definition, we can see the condition:

Thanks to this condition the tasks in the filter in the pool with id=1 and together with the task from the pool id=2 will be displayed. If we want to display e.g. only tasks from the pools which are already finished, we must extend the condition to stateId:

Note: When using the logical operator "|" (OR) it is necessary to use the brackets because of less priority than the expression "&" (AND).

Other examples of the filters:

We can use all the other conditions by the similar way, syntax for each condition separately is described in Help "Features of the task" below the filter definition.

Each filter can be copied and its copy can be saved with a different name. After clicking the button Copy the filter in the form for editing the filter, the name of the filter will be deleted. The new filter will appear in the list adn the previous filter will remain the same after the new name writing and saving it. The filter is possible to modify arbitrarily before saving.

Filter can be deleted by clicking Delete at the given filter. Filter created by TaskPool (default filters of the pools) is not possible to delete, we can only take it away from all the users, so that it will stop displaying in the filters selection at the workplace.

The Condition field defines the circumstances in which the escalation should be sent. The definition of conditions works the same here as for filters, so in case of doubt, read the chapter 7. Filters. Help can be called up again by clicking on individual links below the form.

Figure 8.2. Definition of escalation

Below the condition definition is the Test button, which is used to test the definition and its impact on server performance in terms of duration in ms.

Escalate only on weekdays triggers escalation on weekdays only.

The Repeat option allows you to review and perform the same action on the wallet repeatedly. If unchecked, the action on each tile is performed only once (unless the button is pressed Save & Reset ).

Executed action sets whether the escalation will be used to send emails or execute scripts. Both options are discussed in the following chapters.

Syntax for setting the conditions is the same as at the filters: object.feature. The subject can be the task or the dynamic field. Features of the tasks for escalation are not the same to the features of the tasks for the roles of the filters.

Note: If the condition will be matched, to the given task is changed the mark for sending of the given escalation. It prevents the duplicity of escalations, matching the conditions is checked every minute. This mark is possible to be cancelled by clicking the button Save & Reset. Thanks to it the given escalation will be saved at the tasks, which it was already sent to. The mark of the escalation will be deleted. At that moment the escalations will be sent to all the tasks matching the given condition.

Field "To"

To the field "To" is possible to insert an ID of the user, e-mail address or any other placeholder's strings (this information can be found in the Help below the form). If we use the placeholder's strings, an e-mail will be sent to all users of the given role.

Into the field with the recipients it ís possible to insert more values, or e-mail addresses or placeholder's strings, divided by the semi colon or comma, e.g. "2; 3; josef.novak@taskpool.cz; <#serviceManagers>; <#implementer>".

Field "Subject" and "Text"

Into the field "Subject" and "Text" can be inserted subject and body of the sent e-mail. Placeholder's strings can be also used for the automated filling the values, offered in the section Help "Features of the task".

Placeholder's strings have the syntax <#object.feature> for using in the text. The subject can be the task or the dynamic field. The features of the task are the same as the features of the escalation condition setting and they are placed in the Help below the form.

Sent e-mail as

Sent e-mail can have a form of the simple text or HTML.

Language

Language of the sent e-mail. According to this value e.g. the names of the dynamic fields are filled.

State

Escalation can be deactivated here. It is not necessary to delete it directly, if it is not used temporarily.

Sort of the commentary

After the matching the escalation condition the task is written systemic commentary that the escalation has been sent. In this commentary there is an overall list of the recipients of the escalation message. The form of the commentary can be also set here - public (standard commentary, visible to all, who have the right to see the task), non-public submitters' one (hidden to the implementers) or non-public implementer's (hidden to the submitters). The last offered option is "No comment".

By using scripts we can perform with the task various actions automatically based on a fulfilled condition. This function can be used among other things to automate the workflow, which is repeated in the company, etc.:

...and many others. Script execution conditions are again defined in the same way as for filters. (chapter 7. Filters).

The number of actions the script performs can be any number. Individual commands are separated by a semicolon. The syntax is as follows.

As "property" we can use the value stateId, deadline, assign and waitForAssign. We can change the state of the task using escalation, its deadline, assign tasks to the implementers (possibly propose for allocation), or remove it by the implementer. We can further change the value of the dynamic fields.

On the right side of the assignment can have these values:

'id' | 'name' | 'sequenceid' | 'poolid' | 'stateid' | 'createddate' | 'createdby' | 'takenby' | 'takendate' | 'approvedtime' | 'confirmedtime' | 'finishedtime' | 'handover' | 'tohandover' | 'lastcommentdate' | 'hdnote' | 'hdusername' | 'hdcompany' | 'hduserid' | 'sidetask' | 'price' | 'price2' | 'newprice' | 'priority' | 'deadline' | 'newdeadline' | 'currency' | 'newcurrency' | 'todeadline' | 'slaschemaid' | 'slapriorityid' | 'slapriorityseqid' | 'fixtime' | 'reactiontime' | 'relativefixtime' | 'relativereactiontime' | 'relativeworkingfixTime' | 'relativeworkingupdatetime' | 'relativeworkingreactiontime'

NOTE.: The values, that we assign into the dynamic fields must respect the format of the field, e.g. into the filed of type number cannot be assigned the text string etc. Task time items must be in the format "YYYY-MM-DD", e.g. "2018-03-23". These values can only be applied for the field type textfield, date and datetime. If we wanna change the value of the dynamic field type checkbox, surve as values 'on' and 'off'.

Example 1)

Example 2)

Example 3)

The possibility of obtaining a value in a script type escalation from an external database using an SQL task - (task.name = authentication 12 'name' 'select * from contact where id = <#helpdeskId>')

In the task history on the right side is a list of escalations, which took place over the given task. It is possible to remove it by clicking on the cross.

Figure 8.3. Removing escalation

Records of the users must be searchable in LDAP according to the atributes consisting of ID, which is used for log-in of the user to the PC.

Example:

Then the system requirements must be matched:

These steps must be done necessarily for LDAP authentication good run:

Figure 10.1. Administration: Setting the customer

Authenticator is for automatic log-in to TaskPool, or to Helpdesk thanks to authentication towards the server LDAP. Authenticator finds out the user after run, who is logged in on his/her computer and then opens a window of the browser at the log-in page of TaskPool. TaskPool verifies the data towards LDAP server and logs in the users automatically.

Authenticator can be found in the distribution of TaskPool in the directory "\WEB-INF\tools". There are the directories "TaskPoolLogin" and "HelpdeskLogin". From their names is obvious, that one is for log-in to TaskPool and the other one to the Helpdesk.

Startup files "TaskPoolLogin.bat" and "HelpdeskLogin.bat" can be stored e.g. at the file server and opened remotely. It is not necessary to instal every workstation separately.

The virtual Java Runtime is a condition to run the file at the workstation. It is nowadays the standard part of each operation system. Another condition is functional LDAP authentication configured in TaskPool.

In the administration on the card Licence at the bottom, you can set in the section MFA konfigurace two-factor authenticator. Check for whom it should be required. Save the data and logout off the Taskpool.

Figure 10.2. MFA configuration

Install authenticator on the smart phone device and login. We recommend Google Authenticator or Microsoft Authenticator.

Figure 10.3. Google Authenticator

Login to TaskPool again and window with code and QR code should appear. Using an authenticator you installed, scan the QR code.

ATTENTION! Write the code somewhere safe and save it in case of losing a smart phone device!

Figure 10.4. Code and QR code

After scanning the QR code, a code should appear in the authenticator, which is constantly changing. After login it will pop up the window where you will write into the column MFA code. It will be displayed during every login.

Figure 10.5. MFA code

After clicking the button New the window for a template definition is displayed.

Figure 12.2. Creation a new template

Definition of the templates for the system TaskPool is done thanks to XSLT transformations. XSLT is used for a transformation XML documents or other XML (e.g. for different DTD), into HTML, or into the other types of the files.

Display the list of the tasks is possible to transform into XML format. This display can be gained if we delete last two parameters in the URL address of the task list, (which has e.g. this form: http://www.taskpool.net/list?source=tp.sbs&method=lf&xsl=lf.xsl&format=html) actually everything from the parameter, xsl (URL then will be like this: http://www.taskpool.net/list?source=tp.sbs&method=lf). This display consists of XML list of all the tasks in the current filter, including their characteristics and parameters settings and provides the wide possibilities of exports, which are limited only in your fantasy and company's needs.

When outputs creation it is possible to use e.g. own css templates or pictures, and it is via users' files described in the previous chapter.

Defined templates are saved in the directory /logos/customer_[id]/templates/ in the root directory of TaskPool. The whole directory logos should be backed up, because the information is not in the standard distribution of TaskPool.

Note: Back up is desribed in the installing and upgrade manul in details.

For the template usage directly in the system of TaskPool is only needed to go to the button "Print" in the workplace and the offer of the accessible templates will be displayed for the given pool, the given display and the given role.

Figure 12.3. Templates usage

Placeholder's strings can be used in the text of the notifications. It is possible to set the display of nearly all features of the task and adapt the view of the message.

In the users' notifications is against filters and escalations, moreover it is possible to use the features of the task "history", thanks to which we can obviously see the task's history.

Some features mentioned below might not exist for the given action (e.g. if the task is added a commentary without any other action, then the variable <#task.history.assignedTo> will not be matched). If we use such a variable, no text will be displayed (other variables will work normally).

The features mentioned here cannot use the definition of the condition for the notifications, but only for text configuration!

There is a similar work with the dynamic fields. We can also use the parameters value and name. Their usage is shown in the following table. The way of the usage is then described in the following subchapters.

NOTE: The values "id" represents the identificators of the given dynamic field and it is neccessary to change them according to the specific configuration.

For the definition of the view of the notification's body, it is possible to use several functions, which might make the list more user friendly or highlight the most important information. Functions which enables the work with variables, which return the list (e.g. the list of the dynamic fields or the attachments). Functions, which can be used are:

Functions are described below in detail. Syntax for using the function is:

<block:NameFunction[condition]>
    Code, which should be executed 
<#endBlock>

In an example the element #block is necessary to be used before the function usage and close the code, which should be executed.

Elements #block is possible to group. We can use the function inside the other element #block, but the elements must be numbered. Syntax is then the following:

<block1:NameFunction[condition]>
    Code, executed for function 1 before function 2
    <block2:NameSecondFunction[condition]>
        Code, executed for function 2
    <#endBlock-2>
    Code, executed for function 1 after finishing function 2
<#endBlock-1>

Arbitrary number of functions can be put like this.

<#block:If[task.history.publicId=1 | task.history.publicId=2]>
- hidden commentary
<#endBlock>

<block:NameFunction[variable]>
    Code, which should be executed, in case the variable is filled with data. 
<#endBlock>

<block:NotEmpty[task.history.price]>
    <h2>The change of price was executed,
    new price is <#task.history.price>.</h2>
<#endBlock>

<table>
<#block:Iterate[task.history.dynamicFieldsObj]>
<tr><td><#task.history.dynamicFieldsObj.name></td><td>
<#task.history.dynamicFieldsObj.value></td></tr>
<#endBlock>
</table>

<#block-1:NotEmpty[task.history.attachments]>
     <tr><td colspan="2">Attachments</td></tr>
     <#block-2:Iterate[task.history.attachments]>
                 <tr><td>&nbsp;</td><td>
<a href="http://localhost:8180/file.do?id=<#task.history.attachments.uploadId>">
                 <#task.history.attachments.uploadDesc></a></td></tr>
     <#endBlock-2>
<#endBlock-1>

There is an example of the configured notification. It will be appproximately like that one we know from TaskPool. There are all functions in it.

<html>
<body>
<table>
<tr><td colspan="2"><h5><#task.history.action> (<#task.id>)
    <#block:If[task.history.publicId=1 | task.history.publicId=2]>
    - hidden commentary
    <#endBlock></h5></td></tr>
<tr><td colspan="2">&nbsp;</td></tr>
<tr><td>Message for</td><td><#recipient.firstname> <#recipient.lastname>
          </td></tr>
<tr><td>Who</td><td><#task.history.createdBy.firstname> 
<#task.history.createdBy.lastname></td></tr>
<tr><td>Date</td><td><#task.history.created></td></tr>
<tr><td colspan="2">&nbsp;</td></tr>
<tr><td>Pool</td><td><#pool.name></td></tr>
<tr><td>Subject</td><td>
<a href="http://www.taskpool.net/showJob.do?id=<#task.id>"><#task.name></a>
</td></tr>
<tr><td>Description</td><td><#task.desc></td></tr>
<tr><td colspan="2">&nbsp;</td></tr>
<tr><td>Priority</td><td><#task.priority></td></tr>
<#block:NotEmpty[task.history.comment]>
<tr><td>Commentary</td><td><#task.history.comment></td></tr>
<#endBlock>
<#block:NotEmpty[task.history.price]>
<tr><td>Price</td><td><#task.history.price>&nbsp;
<#task.history.currency></td></tr>
<#endBlock>
<#block:NotEmpty[task.history.price]>
<tr><td>Task Deadline</td><td><#task.history.deadline></td></tr>
<#endBlock>
<#block:Iterate[task.history.dynamicFields]>
<tr><td><#task.history.dynamicFields.name></td><td>
<#task.history.dynamicFields.value></td></tr>
<#endBlock>
<#block:Iterate[task.history.dynamicFieldsObj]>
<tr><td><#task.history.dynamicFieldsObj.name></td><td>
<#task.history.dynamicFieldsObj.value></td></tr>
<#endBlock>
<#block-1:NotEmpty[task.history.attachments]>
<tr><td colspan="2">Přílohy</td></tr>
<#block-2:Iterate[task.history.attachments]>
    <tr><td>&nbsp;</td><td>
<a href=
"http://www.taskpool.net/file.do?id=<#task.history.attachments.uploadId>">
   <#task.history.attachments.uploadDesc></a></td></tr>
<#endBlock-2>
<#endBlock-1>
</body>
</html>

LDAP (Lightweight Directory Access Protocol) is protocol which enables the effective sharing of the structured information for TCP/IP. In reality it means that e.g. list of the employees of the company, their usernames, home directories, personal information, e-mail addresses or telephone numbers. Structure of the information in LDAP can be imagined as a tree, which branches consist of the particular data.

Authentication via LDAP brings two more advantages against authentication via database. The first advantage is the same log in data for all aplications used via the given company. The second advantage is a possibility of automatization of the whole authentication. Log in than can be e.g. via startup file which logs in the helpdesk user into the system automatically (or into TaskPool). This startup file will be sent to you when required by ComArr staff also with the configuration manual.

Helpdesk offers a possibility of full adaptation of each pages layout to the company's needs of course in case of LDAP authentication.

Principle of Helpdesk with LDAP authentication

Principle of authentication without automatic authenticator is the following:

1. The user fills log in and password into the log in screen.

2. TaskPool finds out the user's ID from LDAP.

3. TaskPool receives other information from LDAP server and put them into the helpdesk form. The user is authenticated by this and can create the task. Áll previsou requirements are seen.

4. In case TaskPool does not receive a confirmation from LDAP server about the user's existence and correct log in data, the user is not thought as an authenticated user and has to enter his/her name, e-mail etc. The previous requirements are not seen.

In the picture there is a scheme of log in using the automatic authenticator.

Figure 16.1. Authentication using LDAP

Helpdesk with LDAP settings

This is important for a correct run of LDAP authentication:

• the variables for the access to LDAP server in the setting of authentication

• set a layout of the list of the requirements, which the user has already created to implement

• set a layout of log in screen

Form for creation a new authentication is opened via the button New on the card "Authentication" in the administration section.

Figure 16.2. Creation of a new authentication using LDAP

Using the button Autofill we can insert the access strings into the configuration form for LDAP.

Verification can be even more, Therefore each has its own specific name. User then will during login to Helpdesk, e.g. choose their own firm etc. And like most TaskPool functions, so with verification we can easily deactivate.

LDAP URL

• URL address of LDAP server in the form protocol://adress:port. Example ldap://ldap.youraddress.de:389 and for Secure LDAP ldaps://ldap.youraddress.de:636

User name

• User name which is used for TaskPool log in to the LDAP server. In Active Directory we insert the user name in the form "domain\username".

Password

• Password for log in to your LDAP Server.

Search from

• Specification of the area where TaskPool should search the LDAP objects. It is Search Base. If there are more organization units in your company (e.g. OU=Sales in O=IBM and OU=Development in O=IBM) and OU=sales is not used during the authentication, it is good to limit the usage only to OU=Developement inserting "OU=Development" or "O=IBM" and the process of user's authentication will be quicker thanks to it. In the basic case the domain will be enough, e.g. OU=Development, O=IBM, DC=IBZ, DC=DE.

Use DN for log in

• We determine, if the way to the particular record in the LDAP structure will be added automatically to the log in name: Example:

  • option Active - login filled in the form: "novak", login used for LDAP connection: "CN=novak,DC=comarr,DC=de"

  • option Closed - login filled in the form: "novak", login used for LDAP connection: novak

Note: Active Directory need not require this setting.

Search the sample for the users

• Filter specification when TaskPool will substitute each user to authenticate their identity at LDAP server. E.g. "(uid={0})", where "uid" is a variable with usernames and "{0}" is a substitute character for the user's username. Another example can be "ObjectClass=person". This sample will search only those user, who have in the atribute the type value person.

Note: When Secure LDAP used, the safety certificates into JAVA are needed to import before using LDAP authentication.

SQL for password changing, SQL for inserting the user

• These options are irrelevant at LDAP authentication, TaskPool is not authorized to change access data in the LDAP. This setting can be used when authentication through the database.

LDAP mapping

• It is also needed to enter variables LDAP of objects to their captions. E.g. FirsName: givenName, Surname: sn, E-mail: mail, etc.

The button "Test connection" enables to test the configuration functionality.

Note: Fields "SQL for the password change" and "SQL for user's creation" are irrelevant during the LDAP authentication, TaskPool does not have the right to change the access data in LDAP. This setting is possible to use during authentication via the database.

Configuration of the group of submitters will be described in the chapter 17.3. Manager of the submitters at Helpdesk.

In the section Database it is possible to set the authentication of the logged in users in Helpdesk via the external database (e.g. company's database of its clients). As in the case of LDAP the personal data are loaded from the database and they need not be filled.

This authentication is practically the same as LDAP authentication, only the different basis is used.

When using the database interface you can use very useful tool External Database Manager, with which we can manage the data of external databases right from the TaskPool interface, more in the chapter 20. External Database Manger.

Database interface is configured at the same form as LDAP, type of authentication and database is set at the upper part using the selectboxes.

Figure 16.3. Authentication using the database

DB string

Username and password

Connection pool

SQL for password authentication

Note: At SQL orders configured at the authentication is necessary to write a semicolon at the end of the orders. Help to each SQL order is mentioned below the field for the given order. Thanks to the button "Autofill" TaskPool will fill the basic SQL query to each field.

SQL for the password change

SQL for a user creation

SQL for users selection

Mapping

Funcionality of configuration can be tested by the button Authenticate connection and users mapping. In the picture there is a window which appear after the successful test connection.

Figure 16.4. Test of a successful connection

After the successful connection to the database we can do a login test.

To get database validation up and running quickly it is possible to use preset database. A version for MySQL and MSSQL is available. Both databases are in the directory with TaskPool files:

..\ROOT\WEB-INF\tools\edm\database.MySQL.sql

..\ROOT\WEB-INF\tools\edm\database.MSSQL.sql

NOTE.: In this directory are also found files applicationXml.xml, which serves to activate the already mentioned function External Database Manager. For easy operation of this function, it is possible to use the sample variant, more in the chapter 20. External Database Manager.

To easily start the database, just import the table contained in one of the files to the database server. There we will show the variant for MySQL, for MSSQL is the situation similar.

In the case of MySQL we can import the database in the command line with the following commands:

mysql -uroot -p   //login to MySQL under the user 'root'
create database externalDB;   //database creation
exit;   //exiting MySQL

Now we created an empty database, where we will import the tables from the file database.MySQL.sql in this manner:

mysql externalDB < c:\database.MySQL.sql -uroot -p

Provided, of course, that the given file is located in the root directly on the disk C, otherwise, the full path to the file must be provided. Now you still need to create a user and assign database rights. Of course it is possible to use a user 'root', we recommend to have for every external database special user due to the bigger safety.

mysql -uroot -p   // login to MySQL under the user 'root'
create user extdbuser identified by 'password';   //creating user 'extdbuser' with a password 'password'
grant all privileges on externalDB.* to extdbuser identified by 'password';
   // to user 'extdbuser' we will assign with this command all rights for the database 'externalDB'
exit;   //exiting MySQL

Now the database is prepared you only need to set up authentication, which we will easily do by clicking on the buttonAutofill on the form for creating a new verification. All neccessary items are filled in the configuration form. Only thing we edit is the access to the database itself. Assuming that the database server is located in the local server on the port 3306, the setting will look like this:

Figure 16.5. Authentication configuration using the sample database

Helpdesk also enables to use the role of the manager of the submitters. The manager can see except his/her own requirements also the requirements of his/her subordinates and can add commentaries to them or approve submitted conditions.

The CAS single sign-on system allows the user to automatically log in to all applications that are part of the CAS service upon logon. CAS also supports single logout.

The TaskPool system is usually added to a functional CAS system, but in principle there is no problem to create CAS for TaskPool separately.

TaskPool must register to CAS system with correct URL.

Figure 16.6. CAS configuration example

Note: The Company field displays the ´veřejnost´ name in single quotation marks, indicating that this text string is always written to the Company field.

The appearance of all web forms at Helpdesk is freely configured. The principle of their creation is similar to the classical web page creation thanks to the HTML language. The different is only the creation of each form. Instead of classical HTML fields for input we use the placeholder's strings. These strings make the form creation easier, each placeholder's string represents one field for input at the web form. It is possible to determine, which data in the task will the field represents. The placeholder's strings can be used for a list of certain value, more in the following subchapters.

The list of accessible placholder's strings with the description of their meaning is displayed usually on the left on the card of each form configuration.

Usage of placeholder's strings is simple. The placeholder's string can be only copied (or rewritten) to the required place. In the picture there is an example of the string and the usage in the external link to helpdesk requirement used in the helpdesk notifications. Instead of the placeholder's strings <#id> and <#lang> TaskPool will automatically put the ID to the task and prefered language of helpdesk display.

Figure 17.2. Example of usage of placeholder's strings

The first tab of the Helpdesk configuration is the card "Basic setting". In the header of this field we can see, which pool is related to which Helpdesk.

Helpdesk can be deactivated similarly as the pools and the users. It is not possible to receive the new requirements when deactivated (neither via web nor via e-mail), but it is possible to access the history of the requirements. This is possible to be set thanks to the field State.

Figure 17.3. Helpdesk: Basic setting

Helpdesk identification code is the string, which will be displayed in the link at the helpdesk task. It is for identification of each Helpdesk, it must begin with a letter. The web interface link links to the Helpdesk itself. The entire Helpdesk can be configured in various language versions (see image above). Links are created to the most commonly used languages.

NOTE: You do not need to complete the configuration in all languages, just configure the language version we will use.

The button Administration of forms thanks to archive is for an easy helpdesk forms. After clicking the possibility of download the form from archive will appear. This archive can be then put into the window for uploading the file and TaskPool will automatically process and record all needed forms. The configuration of all forms is then very easy.

Figure 17.4. Helpdesk: Basic setting

After pressing the Download archive of saved forms button the system creates a * .zip archive of all forms of the given helpdesk, its saving to a computer then works in the same way as, for example, downloading files from the Internet. At the same time we can use such an archive to quickly configure a new Helpdesk, or archive to use restore backup. In this case, just insert the archive into the file upload window and after saving TaskPool will automatically process this file and load all the necessary forms. For the correct names of the individual files in the archive must be observed for proper functionality.

NOTE: If we want to use authentication to enter the Helpdesk, this feature allows you to import a sample configuration. The verification is then needed activate in the Helpdesk configuration, this will be done on the "Login" configuration tab, more in chapter 17.12. Card Login .

WWW-interface is for communication with the customer. It enables sending the requirements, viewing the history and a new commentary creation. This link is automatically generated according to the selected identificator of Helpdesk. After clicking, the user will get into the Helpdesk itself.

For Helpdesk integration into the web pages it is possible to use the inframe. It is the frame, which can be easily inserted into the specific place of the web page. Because of the ordinary disadvantages of tabs iframe we do not recommend this implementation. Better is the implementation to insert the separate group, e.g. subdomena in the Helpdesk web interface.

The code for inserting Helpdesk thanks to iframe can be e.g. this one:

<iframe scrolling="no" height="500" width="560" frameborder="0" src=" http://www.taskpool.biz//servlet/HelpdeskDynamic?eid=Helpdesk1&lang=cs "></iframe>

The link must be the same to the generated link at www-interface. The language is possible to select manually; there are three possibilities.

Link to task history behaves similarly. Below the field for its inserting we can find its default image. If we will operate TaskPool at the server localhost:6060, the link will be this one:

http://localhost:6060//servlet/HelpdeskView?id=<#id>&lang=<#lang>

This is a universal URL, where placeholder's strings <#id> and <#lang> will be replaced by the particular values in notifications. If we use e.g. only Czech version of the Helpdesk, the link can be:

http://localhost:6060//servlet/HelpdeskView?id=<#id>&lang=cs

The other tab on this card is Languages. It is necessary to allow at least one language and set, which will be the default one. The Helpdesk allows, as well as the whole system, trilingual variation of display.

TaskPool sends notifications to helpdesk users. Thanks to these e-mails the communication between the implementer and customer (helpdesk user) runs. The customer will receive the notification about the change of his/her created requirement, the body of the notification consists of the link to the requirement history. After the clicking he/she gets into Helpdesk to the history of the requirement and can continue in communication. Sender is similar as at the notifications in the pool, value which will be displayed in the sent e-mail in the field "From". Subject is the same as subject of e-mail.

Rules for sending e-mails and Task creation via TaskPool will be described in the following subchapters.

The default behaviour of TaskPool is, that helpdesk user adds the commentary to the finished requirement, the requirement will be automatically opened. The option Open already archived tasks can be set not to open these tasks. If this option will not be ticked, the finished or archived task with the customer's commentary will not be opened.

The option Change of helpdesk user enables to create tasks at Helpdesk on behalf of somebody. In reality the helpdesk user can select the other user from the given authentication after log-in to Helpdesk. The task will then be created (see more in the chapter 17. Authentication). Thanking to the requirement will be received to the user, not to the submitter on behalf with an address at its history. The other checkbox in the setting is for the changes of the user and if they will be written into the task history or not.

Note: It is necessary to have the placeholder's string in the helpdesk form <input name="hd_autocomplete" /> for the correct function of the helpdesk user change, which enables to select the particular user.

Rules for e-mail sendings

Workflow creation of implementing the helpdesk requirements is the following:

1. Creation of the requirement by helpdesk user (customer)

2. Assignment the task by the implementer

3. Communication from the implementer's side

4. Communication from the submitter's side

5. Implementing the requirement by the implementer and finishing the task

6. Possible acknowledgements by the submitter or returning the requirement to the implementer to revision

In the section Rules for e-mails sendings is possible to set, which actions will be used for sending the notifications to the helpdesk users. It is set by default, that any time the implementer will do an action (assignment of the task, commentary, finishing the task), the submitter is informed about this action by notifications. Moreover for requirement creation the user will receive the thanking for the requirement with an address to its history automatically. Thanks to the checkboxes in this section we can select manually an access of sending these notifications. For example, we will cancel all automatic notifications sendings. Setting the checkboxes then will be like this:

Figure 17.5. Setting the helpdesk notifications

In this case the helpdesk customer will not be automatically informed about any actions, which a implementer does with the task, not even about the successful creation of the requirement (thanking). We have a possibility to inform the helpdesk submitter manually at arbitrary change of the helpdesk task. If at least one checkbox in the setting of e-mails sendings is not ticked, in the window of task change in TaskPool there will appear an option e-mail HD. If this field is ticked, than after saving the task the helpdesk user will be sent a notification about the task change. It is on the implementer, in which cases the submitter will be informed about the requirements.

Figure 17.6. Send a message to the HD user

Creation of the HD task via TaskPool

Helpdesk task can be created directly in TaskPool's solution interface. Thus we can enter a task on behalf of a helpdesk user, ie a customer. In practice this means that when entering the task, we fill in the customer data and after saving the task, the user will be thanked for the request, similarly as if he entered the request himself on the Help Desk. If you want to use this option, at least one of the roles must have permissions in the pool. This will be done in the "Create TaskPool" section. Here we also set whether it is possible to enter classic internal tasks in the helpdesk pool.

Figure 17.7. New HD task

Note: Function Co-submitters is only available when using authentication. The principle is similar to that of co-investigators. The co-submitters sees the tasks in his list of helpdesk requests, has the opportunity to comment on it and receives notification.

Nearly every helpdesk page consists of common features (e.g. header and footer), TaskPool enables to template helpdesk. The common code, saved in a separate file, it is possible to upload into the section "Files" (see the chapter 11. Files). To this file than could be refered to any page this way:

Work with templates is possible to extend about parameters sendings. It enables e.g. easy change of logo at each Helpdesk. In the files' saved template must be this code:

<img src="<#template_attribute name="logoCompany">" />

Name of the parameter is in this case "logoCompany" and there can be used the string at any length without diacritics. It might be:

<#template_include file="HDheader.html">
<#template_param name="logoCompany"
   value="http://www.taskpool.net/img/ref_comarr.gif">
<#template_include_end>

As a parameter "logoCompany" will be sent URL "http://www.taskpool.net/img/ref_comarr.gif" into the template "HDHeader.html".

For displaying the particular elements it is possible to use the conditions. We can e.g. provide displaying the particular element only, when the task is finished, if the user is authenticated (more about authentication in the chapter 17. Authentication) etc. The most common conditions are these:

<#if "user_authenticated">
   <a href="<#hd_overview_url>">Your requirements</a>
<#endif>

This condition provides the display of the list of requirements to the authenticated users only.

<#if "roleId == 2">Text for the submitter<#endif>
<#if "roleId == 16">Text for the manager of submitters<#endif>

Thanks to this condition we can determin, which role will the text be displayed to.

<#if "stateId = 202">
   New conditions were submitted, do you agree? <#hd_customer_confirm>
<#endif>

Thanks to this condition it is possible to display the content of the requirements state. This particular case is for confirmation of the conditions at Helpdesk. If there are new conditions submitted by the implementer (price, deadline), task will change into state with id=202 and the Helpdesk user will be displayed the selectbox where these conditions can be accepted or declined.

HD form is the page, where the customer creates his/her requirements. The contact data (name, e-mail, telephone) are filled here, also the description of the problem and optionally other values (SLA, priority, co-submitters etc.).

For each entrance fields display there are placeholder's strings used, described in the chapter 16.1. Usage of placeholder's strings. Instead of each placeholder's string the entrance field for the text will be insterted automatically into the mailbox, (or also for attachment insert).

Elements <form> and </form> is not possible to write manually! These elements of TaskPool will be generated automatically and when writing manually, Helpdesk will not work!

The basic scheme of the form is available after clicking the link Show sample code. The principle of function of the placeholder's strings can be understood from the sample code. Their description can be found in the left part of the page of the form configuration. In this part of the page it is also possible to select, which values will be obligatorily required when filling the form. If the field is labelled as obligatory, TaskPool will automatically put the star to it. In case of the field will not be obligatorily filled and the form will be sent, the page with an error report will appear.

At this page it is also possible to set the size of the field for a description of the requirement and a text of a submit button.

Figure 17.8. Helpdesk: HD Form

The resultant helpdesk form can be e.g. like this one:

Figure 17.9. Example of helpdesk form without authentication

Figure 17.10. Example of helpdesk form with authentication

Note: When authentication usage, the user need not fill in his/her personal data. This data is loaded from the database during the user's authentication. At the same time at the form without authentication, the list of assigned requirements and a function co-submitters is not accessible. These functions are possible to use only with active authentication.

If the co-submitter will be selected, he/she will be able to see this requirement in the list of requirements. He/She can also add some commentaries and the notifications will be received. The embed code is as follows:

<#if "!user_authenticated">
  <tr><th><label for="captcha"></label></th><td><img src="../captcha.jpg"/></td></tr>
  <tr><th><label for="captcha2">Opište kód z obrázku*</label>
      </th><td><input type="text" name="captcha_key_name"/></td></tr>
<#endif>

The page of error report will be displayed to the customer in case, he/she has not filled all obligatory fields. For return to the creation form we recommend using Javascript link (see the sample code), not to lose the filled data and necessity to fill them in again.

In the code of the helpdesk form it is possible to validate the form by Javascrip. The error report might not occur then. In the form of the previous picture there are all these cases validated by Javascript. This form can be sent if required by ComArr staff or using the function "Management of the forms thanks to archive" described in the chapter 16.2. Basic setting.

Figure 17.11. Helpdesk: Error reports

After the successful requirement there will be a thanking sent to the helpdesk user together with the link to the task history, or e-mail will be sent with this information (see the setting in the chapter 16.2. Basic setting).

On this card we define a layout of the web and an e-mail thanking. There is also a sample code available.

Web thanking can be e.g. like this:

Figure 17.12. Example of web thanking

On this card we define the automatic signature, which we can use when answering helpdesk requirements directly in TaskPool. This function can be used only in TaskPool, not at Helpdesk. We can use all placeholder's strings mentioned on the left.

Figure 17.13. Helpdesk: Signature

Signature can be insterted when the task modification and after clicking the button Signature. Automatic text will be inserted below the written commentary, independently to actual position of the cursor.

Figure 17.14. Automatic signature in reality

Notification is sent to the customer, if the implementer makes a change with his/her requirement (commentary, takeover, finishing etc.). In case of e.g. hidden commentaries or addition of the subtasks to the notification requirement, the customer is not sent anything. There should be a link to the web page in the notification, where the customer has a possibility to add a new commentary, at the requirement history. Notifications are configured the same way as e.g. layout of the e-mail thanking.

History of the requirement is helpdesk equivalent to detail of the task in TaskPool. Helpdesk user has a possibility to see the chronology of the requirement implementing and also he/she can add commentaries or attachments. There are also all actions with requirement list, of course except hidden commentaries at the implementer's side etc.

Header

Header is the top part of the web page of the requirement history. In the setting of the header it is possible to insert placeholder's strings for information about the requirement and for adding a commentary (form for the answer), we recommend placing this window to the lower part of the screen. Otherwise, the helpdesk user can add his/her commentary into the implementer's window.

In reality the header can be like this:

Figure 17.15. Example of a header of the requirement history

List of commentaries

Into this section we can insert a sample for each commentary display. TaskPool than uses this sample to each display.

Figure 17.16. Example of list of commentaries of the requirement history

Footer

Footer is the lower part of the web page of the requirement history. Into the footer there is possible to place the same placeholder's strings as into the header.

Note: Header and footer of the requirement history is not the same as the header and footer of the overall web interface of Helpdesk!

Figure 17.17. Example of footer of the requirement history

The list of the tasks works only for the authenticated users. Without authentication the list of their requirements cannot be displayed. If the user logs in Helpdesk, via LDAP or external DB (see the chapter 17. Authentication), it is possible to personalize him/her in the helpdesk system.

The card Tasks list shows the list of the requirements created by the particular users. The additional features are possible to be displayed to the requirements for better orientation. If the user does not log in to Helpdesk at any of the ways mentioned, the content of the forms is not available to him/her.

Header and task list

Header is an upper part of the web page in the requirements list.

Thanks to this part the list of the requirements of the given user is listed here. Similarly to the task history there is defined the sample for each requirement display and TaskPool will use this sample for displaying the other ones.

Right next to Search are located buttons Active and All. You can edit and expand them with other items:

Figure 17.18. Example of the tasks list

Footer

Footer is the below part of the web page in the requirements list of tasks. Again there is possible to use the placeholder's string <#hd_user_id_extern>. In the tasks list the footer is used mainly for closing the elements </table>, </body> etc.

TaskPool saves the data about logged in user into the cookies of the browser. Until the window of the browser is closed, the user will not be logged out and when he/she enters the next time, the name and the password will not be required in the form. The link to the manual log out may be possible to create via placeholder's string <#hd_o​vervie​w_url>​&hd_lo​gout_b​utton.

On this card it is possible to set, if the users can access Helpdesk without log in (anonymously) or using log in (authenticated) or if both possibilities will be allowed. If we want to access Helpdesk, we must define the authentication first. It is the function which enables to access Helpdesk with log in and password (see the chapter 17. Authentication).

Access to Helpdesk thanks to authentication is advantegous. The first advantage is automatic personal values load (name, telephone or address of the user) when a new helpdesk requirement creation. The second advantage is a possibility of monitoring and implementing all the requirements, which were created by the user.

In the upper part of the screen we have a selection of each authentication and anonymous access. At the required authentication it is necessary to tick the applicable checkbox and fill in the order. We recommend a special authentication for each pool (company). Of course it is possible to have one authentication for all Helpdesks, but this implementation is not recommended.

Figure 17.19. Helpdesk: LDAP/DB

According to the setting in the picture it will be possible to acces Helpdesk anonymously as well as via authentication. Into the requirement created under the authentication it will be also possible to enter only after authentication. If we select the field Veficiation needed as non active, it will be possible to enter into all requirements of Helpdesk without authentication.

For the code to the log in page we can use the sample text. Please pay attention to this line:

<select name="hd_authentication"> <#hd_authentication_options> </select>

These are the placeholder's strings of selectbox for authentication selection. If we use only one authentication for a given Helpdesk, this selectbox is not necessary to display. It is an obligatory element, therefore we cannot delete it completely; authentication will not work then. We can hide it this way:

<select name="hd_authentication" style="display: none;">
<#hd_authentication_options></select>

Figure 17.20. Example of log in screen

On this card we can configure the forms for the password change of the authenticated helpdesk users or for a renewal of forgotten passwords.

Password change is via usual scheme - insterting the current password, by insterting a new and renewal the password. Again it is a sample code here.

Figure 17.21. Example of password change

Renewal of Forgotten password is for the users, who have the account, but have forgotten the password to it. For the correct function it is necessary to configure a web form and an indicative e-mail, but also the form without a password change! The renewal of the forgotten password does not work on the principle of the password change. After insterting the user name and e-mail address from the profile the indicative e-mail will be received to the given address. This e-mail must consist of a string <#hd_changePassword_url>, which represents URL form for the password change to the user's account.

Figure 17.22. Example of forgot password screen

On this card it is possible to configure the form for registration of the new helpdesk user. Thanks to this form the users will be possible to register their own log ins. There are possible both variations at once. If we want to access the Helpdesk openly, we need to define validation first, see more in the chapter 16. Authentication.

Lets repeat, that the acces to Helpdesk using the authentication brings several advantages. First advantage is automatic loading of personal data (name, e-mail, telephone number etc.) when entering a new one helpdesk task. The second biggest advantage is the possibility of clear tracking and handling all tasks, which the given customer entered into the system.

At the top of the screen we have a choice of individual verifications and also the so-called anonymous access, which serves for entry without login. For the required verifications you need to check the relevant checkbox and fill in the order. We recommend to have for ervy pool (firm) special verification. Of course it is possible to have one verification for all Helpdesks, but we do not recommend this solution.

Figure 17.23. Example of registration

According to the setting on the picture it will be possible to access the Helpdesk both without logging in (anonymously) and with authentication. To the tasks written under verification will be possible to access again only after the verification. If we choose the field Verification required as inactive, without verification it will be possible to get into all of the tasks of the given Helpdesk, including the ones that are assigned under the verification.

Link to this page with registration will be used in the form:

<a href="<#hd_createUser_url>">registration</a>

This link can be found in Help of the placeholder's strings on the left side of the screen.

For the login page code we can follow the sample text again. However, lets pay more attention tho this line:

<select name="hd_authentication"> <#hd_authentication_options> </select>

If we use more verification in the given Helpdesk, using this selectbox when loggin in, we choose specific of them. If we use for the given Helpdesk only one verification, this selectbox does not need to be shown. However, it is a mandatory element, that is why we can not fully remove it, the verification would become unfunctional. We can hide it this way:

<select name="hd_authentication" style="display: none;">
		<#hd_authentication_options></select>

We recommend reading the chapter 14. POP3 assignement first. Each e-mail address is possible to assign to the particular Helpdesk users. These users must log in via one of the authenticated mechanisms (see the chapter 17. Authentication). If the particular e-mail address is assigned to the particular user, then e.g. at receiving requirement via e-mail from this address the system from POP3 mailbox will select and transfer it to the helpdesk task. It behaves as it was created by this particular user. The information about the user are also put to the task. Previous e-mail address from which the requirement was received is than saved into the dynamic field of the task.

The users can be assigned not only to the particular address (e.g. adam.novak@taskpool.cz), but also to the group of addresses (e.g. only @taskpool.cz). The language version can be also assigned.

The procedure for creation and assingment is the following:

With the Map all users button, TaskPool will automatically map all users from the given database to an email, which they have saved in the database.

Checkbox Map all users automatically ensure, that every newly added user to the database will be automatically mapped.

We recommend reading the chapter 3.10. E-mail Interface first. Another option is to structure the incoming e-mail into more information.

Figure 17.26. Helpdesk: e-mail interface

Structuring the e-mails is shown in the picture. In this case the line begins with the string "Text:" it will be transfered to the task description, the line beginning "Expire:" will be transfered to the task deadlilne etc.

According to Unique values the existing helpdesk task in the given pool is searched (fox example Text: action001). In case of unity, the text of the incoming e-mail will be connected as a commentary to this task (be careful not to overwrite the Task Name with the name of the new e-mail). Otherwise TaskPool will create a new helpdesk task. Unique value is not obligatory data.

If the field Accept all e-mail addresses is ticked, all e-mail addresses will be considered as a sender, to which a given e-mail was received, and it is including the addresses, the copies were also received to. In case the field will not be ticked, the sender will be considered only the address of the real e-mail sender.

Option Ignore by expression can be used to discard incoming emails, which meet the specific parameters, for example:

mail.from == email1@domena.cz or mail.from == email2@domena.cz (ignores emails from the listed addresses)

mail.subject == text1 (ignores emails with an expression "text1" in the subject

mail.body == text2 (ignores emails with an expression "text2" in the body)

More information about syntax can be found on the manufacturers website: http://commons.apache.org/proper/commons-jexl/reference/syntax.html

In case we want to Use TLS verifying, it is neccessary, besides checking this field, to import into Java a tool "Keytool" according to the instructions at this address: https://docs.oracle.com/javase/8/docs/technotes/tools/#security

Overall configuration of arbitrary Helpdesk can be copied among the pools. In the list of pools it is enough to click the button "Copy the Helpdesk", at that pool, which configuration of Helpdesk we want to copy. After clicking, the window will appear, where we will select only a target pool, into which the configuration should be copied.

Figure 17.27. Copy the Helpdesk

If the target pool already consists of active Helpdesk, the query about rewriting the existing configuration will appear.

SLA time is defined in SLA schemes. They are defined either in days or in hours.

RT (Reaction Time)

FT (Fix Time)

For SLA run it is necessary to create SLA scheme and assign it to the pool, which we want to work in. Creation is done in the administration (bookmark SLA modules -> New), assignment to the pool is done on the card "SLA scheme" in editation of the pool (see the chapter 3.7. SLA schemes).

Figure 18.1. SLA time configuration

In SLA configuration the time mean "from" and "to", when the given SLA time is counted. It is actually working time, when the tasks are implemented. For every priority it is possible to set its own time. Then it is possible to define public holiday, which are included into not working days for all priorities. If we follow the setting from the picture, then e.g. task with priority 1 will be implemented always Monday-Friday from 8:00 to 20:00, RT will be 4 hours and FT will be 8 hours. It means that the task must be taken over up to 4 hour and up to 8 hours the task must be implemented. All in working time.

If the task is created in the working time, nothing is changed. E.g. if we set the task with priority 1 on Monday at 8:00, then the task must be taken over at 12:00 and at 16:00 the task must be implemented. If the task is created before the working time or on not working day, the time when SLA starts to count, the beginning of the working time will be set to the closest (current) weekday. If we create the priority 1 e.g. on Sunday at 22:00, then the beginning will be set to Monday 8:00 and every time will be the same as if we set the task on Monday 8:00. All of it in case Monday is not defined as public holiday. If it is a public holiday, then the start will be set to Tuesday 8:00. Except the set working time the time is not subtracted.

For each schema, you can set whether or not to Add new reaction time after task refusal which re-enables the SLA calculation and in in states Waiting for information and New conditions stops SLA counting.

SLA calculation can be a computationally demanding operation, so it can be set to optimize server performance Period of calculation (from 1 minute up - default value is 5 minutes)

Note.: For each priority at least one weekday must be set.

Parameter to specify the time window (in days), for which is SLA calculated: sla.calendar.start=-4000 sla.calendar.length=10000. This will reduce recalculation in SLA and speed up the server.

Activated SLA is a different display of the column "Deadline" at workplace. Classical deadline is displayed only as a number of days until expiration and the expiration date, SLA displays two mentioned times.

Figure 18.2. Display without active SLA (deadline yesterday)

Figure 18.3. Display with active SLA (Reaction tomorrow)

Where "R" means Reaction Time and "F" means FixTime.

The following rules are counted:

We distinguish two types of FT:

This manual FT is possible to change back to the automatic one. Again you have to accept the dialog, that you want to modify FT. In the field "New conditions" will be displayed the button "Count according to SLA", which sets FT to its original value.

If already created tasks exist, and the SLA scheme is decided to be changed, then we have several possibilities. When saving the used SLA scheme to TaskPool, you will be asked the following procedure:

Figure 18.4. Re-calculation of the manual time according to SLA

We have a possibility to set, if we want to recalculate those tasks which have set the automatic FT (deadline) according to a new scheme. There are three options:

First you need to unzip the EDM source code into the Tomcat directory "next to" the TaskPool. If the TaskPool files are for example in the directory ..\Tomcat 8.0\webapps\ROOT , EDM files unzip into the directory ..\Tomcat 8.0\webapps\ExternalDatabaseManager\ .

Next into the folder ..\ROOT\logos\customer_1\ create the subfolder ..\ROOT\logos\customer_1\externalDatabaseManager\ , where we will place the EDM configuration file called applicationXml.xml.

Similar to the authentication configuration and Helpdesk, and even there, the possibility of quick commissioning of EDM using a sample configuration is offered. Can be used in case, that we used a sample database for verification (more in the chapter 16.3. Using a sample database. In that case, just copy the configuration file:

..\ROOT\WEB-INF\tools\edm\applicationXml.xml

into this directory:

..\ROOT\logos\customer_1\externalDatabaseManager\

In configuration file set only access to the databsse and verification for individual users. Complete configuration of this file is dedicated in the upcoming subsection.

One or more applicationXml.xml files can be configured. You can choose between these files in the EDM afterwards.

For the correct function of the EDM you need to correctly configured the file applicationXml.xml.

<Application>
    <!-- name displayed in the header of the page -->
    <Name>EDM</Name>
    <!-- write version, at every change in the file, the version needs to increase by one,
         so that the Taskpool knows that the file has changed -->
    <Version>1</Version>
    <!-- users login, which has access to the EDM -->
    <Access>
        <User>
            <Username>admin</Username>
        </User>
        <!-- access to the EDM can optionally be enabled for more users this way -->
        <User>
            <Username>login2</Username>
        </User>
    </Access>
    <!-- URL for connecting to the EDM database, not to the TaskPool db!
         Example for MySQL -->
    <Database>
        <URL>jdbc:mysql://localhost:3306/databaseName?
             characterEncoding=utf8</URL>
        <Username>login</Username>
        <Password>password</Password>
    </Database>
    <ManagerUrl>
        <!-- URL location EDM for communication between EDM and TaskPool -->
        <CommunicationUrl>http://www.taskpool.net/ExternalDatabaseManager/
          </CommunicationUrl>
        <!-- URL location EDM for web browser -->
        <BrowserUrl>http://www.taskpool.net/ExternalDatabaseManager/
          </BrowserUrl>
        <!-- TaskPool URL -->
        <TaskPoolUrl>http://www.taskpool.net/</TaskPoolUrl>
		<!--  id verification (if filled, no need to more define the Database -->
	    <TaskPoolAuthId>2</TaskPoolAuthId>
    </ManagerUrl>

    <!-- If we used a sample database, it is possible to end the configuration here. 
	In this upcoming part we configurate the specific tabs and columns in the database. -->

    <Objects>
        <Object>
            <!-- name of the table in the database -->
            <Name>company</Name>
            <Legends>
                <!-- name, which will be displayed in the tables overview  -->
                <Overview>Companies</Overview>
                <!-- name, which will be displayed in the detail view of one record -->
                <Detail>Company</Detail>
            </Legends>
            <!-- description, which will be displayed as backreference
                 and reference,more below -->
            <Label>{id} - {name}</Label>
            <!-- definitionof each property corresponds to one column in the table -->
            <Properties>
                <Property>
                    <!-- Name of the column in the database -->
                    <Name>id</Name>
                    <!-- name, which will be displayed in the EDM -->
                    <Legend>ID</Legend>
                    <!-- if it is true, the value will be displayed in the item list of the table, 
						if it is false, it will be displayed only in the detailed view of individual items -->
                    <ShowInOverview>true</ShowInOverview>
                    <!-- true if the value is automatically generated and it is impossible to change it, 
						this element is optional -->
                    <Generated>true</Generated>
                </Property>
                <Property>
                    <Name>name</Name>
                    <Legend>Name</Legend>
                    <ShowInOverview>true</ShowInOverview>
                </Property>
            </Properties>
            <BackReferences>
                <BackReference>
                    <Name>contact</Name>
                    <Property>companyId</Property>
                    <Legend>Contacts</Legend>
                </BackReference>
            </BackReferences>
        </Object>

        <Object>
            <Name>contact</Name>
            <Legends>
                <Overview>Contacts</Overview>
                <Detail>Contact</Detail>
            </Legends>
            <Label>{id} - {firstname} {lastname}</Label>
            <Properties>
                <Property>
                    <Name>id</Name>
                    <Legend>ID</Legend>
                    <ShowInOverview>true</ShowInOverview>
                    <Generated>true</Generated>
                </Property>
                <Property>
                    <Name>username</Name>
                    <Legend>Username</Legend>
                    <ShowInOverview>true</ShowInOverview>
                </Property>
                <Property>
                    <Name>password</Name>
                    <Legend>Password</Legend>
                    <ShowInOverview>false</ShowInOverview>
                </Property>
                <Property>
                    <Name>firstname</Name>
                    <Legend>Firstname</Legend>
                    <ShowInOverview>true</ShowInOverview>
                </Property>
                <Property>
                    <Name>lastname</Name>
                    <Legend>Lastname</Legend>
                    <ShowInOverview>true</ShowInOverview>
                </Property>
                <Reference>
                    <Name>companyId</Name>
                    <Legend>Company</Legend>
                    <ShowInOverview>true</ShowInOverview>
                </Reference>
                <Property>
                    <Name>email</Name>
                    <Legend>Email</Legend>
                    <ShowInOverview>true</ShowInOverview>
                </Property>
                <Property>
                    <Name>phone</Name>
                    <Legend>Phone</Legend>
                    <ShowInOverview>true</ShowInOverview>
                </Property>
                <Property>
                    <Name>note</Name>
                    <Legend>Note</Legend>
                    <ShowInOverview>false</ShowInOverview>
                </Property>
                <Property>
                    <Name>isManager</Name>
                    <Legend>Manager</Legend>
                    <ShowInOverview>true</ShowInOverview>
                    <Html type="1">
                        <Options>
                            <Option value="1">Yes</Option>
                            <Option value="0">No</Option>
                        </Options>
                    </Html>
                </Property>
                <Property>
                    <Name>isActive</Name>
                    <Legend>Active</Legend>
                    <ShowInOverview>true</ShowInOverview>
                    <Html type="1">
                        <Options>
                            <Option value="1">Yes</Option>
                            <Option value="0">No</Option>
                        </Options>
                    </Html>
                </Property>
            </Properties>
            <BackReferences/>
        </Object>
    </Objects>
</Application>

A table column often shows a foreign key of another table. If we want to display the value from this table and not just the value ID, we use instead of <Property> element <Reference>.

<Object>
	<Name>lokalita</Name>
	<Legends>
		<Overview>Lokality</Overview>
		<Detail>Lokality</Detail>
	</Legends>
	<Label>{id}- {name}</Label>
    <Properties>
        <Property>
            <Name>id</Name>
            <Legend>Lokality</Legeng>
            <ShowInOverview>true</ShowInOverview>
        </Property>
</Object>

In case we want to refer to the previous record, we use the element <Reference> then:

<Reference>
    <Name>lokality</Name>
    <Legend>Lokality</Legend>
</Reference>

After that instead of the value "ID" will be displayed "ID - name". When editing a record, a selectbox will be displayed instead of a text field in the detailed view , which displays the values from the table "Lokality". But the foreign keys must be defined, thus created a link between the tables.

Next imagine a table "contact" containing foreign keys from the table "company". One firm can have several assigned users. If we want to in the firms value detail show all users records, which contains foreign key (id_contact),we use the element <Backreference>. The content of the element <Name> specifies the name of the object, <Property> property name from the object, which is already contained in the EDM and <Legend> name displayed in the EDM. The element <Backreference> is added after the element <Properties>.

<Backreferences>
    <Backreference>
        <Name>contact</Name>
        <Property>id_contact</Property>
        <Legend>User</Legend>
    </Backreference>
    <Backreference>
        <!-- next record -->
    </Backreference>
</Backreferences>

If we want to display a different value in the report, than it is stored in the database, we use the property <Options>.

<Property>
	<Name>id</Name>
	<Legend>ID</Legend>
	<ShowInOverview>true</ShowInOverview>
	<Html type="1">
        <Options>
            <Option value="1">Value 1</Option>
            <Option value="2">Value 2</Option>
            <Option value="3">Value 3</Option>
        </Options>
    </Html>
</Property>

Normally the table entry would show the "ID" value, now will be displayed Value 1, Value 2, Value 3. The selectbox will be displayed in the record detail, instead of the text field.

From version EDM 1.145 it is possible to track accesses and changes in the EDM database using a log. It is stored in ./WEB-INF/logs/.

Locked record cannot be edited by any user. The right to lock the record belongs only to the administrator by default. But he/she can assign it to the other users via the button Edit settings on the card "Cost evidence". This form will appear:

Figure 21.3. Common settings - Cost evidence

If the records are locked until 31/12/2018, as we can see in the picture, those records created after this date can be edited, but not the older ones. If the right to lock the records is assigned to the other users, they will be offered "Other actions" option "Timesheets locking and reporting" at their workplace. After clicking on it this form will appear:

Figure 21.4. Records lock at the workplace

Only date is needed to be set until the records are locked and save the settings.

In TaskPool, each user has the option to export his / her time records, as described in the user manual in chapter 3.6. Export of timesheets.

Billing provides a quick and easy way to select specific time records and export them to an external file or prepare for printing, eg as a basis for an invoice. The function is not primarily designed for billing, we recommend using it for export time records to other systems, respectively. for creating delivery notes. The advantage of this feature is possibility of posting time records from unfinished tasks.

Note: Every user who has a right to create bills has the right the right to lock time records.

Click the button Billing in the "Other actions" menu on the workplace we get to the screen for creating and editing individual bills. We recommend creating a separate bill for each project.

Figure 21.5. Billing List

To create a new billing form use the button New in the menu on the left of the screen. Anytime billing any of the users edits, at that moment the other billing is locked and currently edited by other users the user is displayed in the "User Locked" column. After editing by the user this information will disappear. The cross is used for manual cancellation if the user is editing for some reason he didn't finish editing.

Figure 21.6. Locked billing

The billing process itself is as follows:

Figure 21.7. New billing

On the first screen, fill in the Number and Name (both can be changed later). Once you open your billing, we will begin to select specific records of the time that will be included in your billing.

By default, all time records from the entire database are offered in the list user right to see. Use filters at the top of the screen to refine their selection. Then just check the records to be included in the bill. We confirm the selection button Save.

Note: As a rule, every time record can belong only into one bill. For this reason, we recommend creating at least one bill for internal performances that are not charged to the customer. This will not interfere with the list of records when creating another bill for the customer.

Figure 21.8. Adding records to billing

As long as we keep the billing open, we can continue to make changes to it. After closure is no longer editable. There is also a third "Canceled" status. The we will use where the billing has lost its meaning for some reason. The advantage of switching to this is the fact that all the time records contained in it become free for other billing.

ATTENTION! Canceling a bill is an irreversible action!

We can export each bill using the button Print in list of billings. There is a standard "Billing" template to prepare records for printing. It is also possible to use other templates, eg for the mentioned export to other systems etc., the issue of export templates is described in the administration manual in chapter 12. Templates. When using the standard template we get roughly this result:

Figure 21.9. Print template of billing

If more than one template is displayed in the print list, ask for your training administrator.