Tasks

Tasks

The “Tasks” application in OpenGroupware is a full-featured task manager with tight integration with the “Projects” application. While it can be used as a simple to-do utility it's full potential is only realized when utilized as a groupware application.

A task

Creator, Owner, & Executor

A task is associated to three accounts; the creator of the task, the owner of the task, and the current executor. Many interfaces refer to the executor as “owner”, however in most cases the actual creator of the task is irrelevant: for practical purposes the owner as the originator of the task and the executor is the one who is expected to perform the task. The creator and owner of a task are always accounts, while the executor may be either a team or an account.

When a user creates a task they can select an executor; if they select no executor the executor of the task will be set to the user's own account (owner and executor will be the same). Selecting an executor other than oneself is referred to as “delegation”. Delegation is the act of placing a task on another user's to-do list. If a task is delegated to a team (the executor is set to a team) the task will appear on the to-do list of every user who is a member of that team. Not all clients support delegation1; for instance with Microsoft Outlook or any of the GroupDAV clients a task is always created with the executor set to the creator. To support task delegation users must use either the WebUI or a client that uses an OpenGroupware.org specific API or protocol such as zOGI.

The owner of a task will always be the creator except in the where the help-desk role is being used. The default “OGoHelpDeskRoleName” can be used to define a single team as having the help-desk role. Users who are a member of that team can create tasks and set other users as the the owners of the task: essentially creating a task on behalf of another user. Such a task will appear on the delegated task list of the owner, not the creator.

If the “preferred executant” feature is enabled on your OpenGroupware instance then a user selecting a team as the executor for a task will have the additional option of selecting one or multiple members of that team to act as preferred executors. See “Preferred Executant” in the “Customization” section of this chapter for details on preferred executors.

Task Workflow

The life cycle of a task is divided into a series of states. A task can be in one of six states: “created”, “accepted”, “rejected”, “processing”, “done”, and “archived”. However, you will never find a task in the “accepted” state as once a task is accepted it is immediately updated to the “processing” state; the purpose of the “accepted” state is only to record the event of a user accepting a task.

Creating a task

When a task is created it must be assigned to an owner; the owner can be either an account or a team. If a user creates a task and selects themselves as the owner then the task is immediately placed on their “to do” list in an “accepted” state. If a user selects another user as the owner the task is immediately placed on that users “to do” list in a “created” state. The creator of the task will see the newly created task in his or her “delegated” task list. The creator retains the ability to “annotate”, “mark as done”, and “archive”. The user who is the owner can either accept the task, reject the task, or mark it as done.
If a user selects a team as the executor of the the task then the task will appear in the delegated tasks list of the creator and on the “to do” list of every team member.

Rejecting a task

Accepting a task

If the creator of a task selects him or her self as the owner of the task then it is accepted immediately.

If a task is delegated to a team then any member of that team can accept the task. Once a member accepts the task the owner will be changed to that account and the task will no longer appear on the “to list” view of the other members task lists.

Marking A Task As Done

If the owner of the task marks a task as done it will then appear only on the creator's task list. If the owner is the creator it will appear as status done on their “to do” list. If the creator was another user than the owner it will appear in the creator's “delegated” tab. If the creator marks a task as done that was delegated to another user that task will appear as “done” in both the creator's “to do” list and “delegated” tabs, but no longer appear on any of the owner's task lists.

Archiving A Task

If the creator archives the task at any point it will move to the creator's “archived tasks” tab and disappear from the owner's task lists. Only the creator of a task may archive a task. Once a task is archived it can no longer be edited or annotated.

While the web interface provides no mechanism to revert a task from archived to another state it is possible to make an annotation to an archived task via either the XML-RPC or zOGI API that changes the state of the task back to created.

A task must be archived before it can be deleted.

Task Attributes

A task has numerous attributes which describe the job or action to be performed and how it will be tracked.

• Task Name – A brief description of the task, this can also be considered the title of the task.
• Start Date / End Date – Describe when work on the task should commence and the data at which it is expected to be completed. The start date may be in the future but may not be in the past; the end date must be later than the start date. In most applications the start date of a new task will default to the current date and the end date to a week later.
• Completion Date – Records when the task was actually changed to a “done” state. This can be used to track how often tasks are completed on or before (or after) their expected completion date (the “End Date” value).
• Keywords – This is a free-form field used to store a list of whitespace delimited terms that can be used to search for the task. Any related names or values that can later be used to retrieve the task are good candidates to be included in “Keywords”. “Keywords” is not expected to be a formal sentence, merely a list of whitespace delimited terms.
• Category – Category is used to categorize tasks. Various user interfaces present this field as either a free-form value or a list of predefined values from which a value can be chosen.
• Percent Complete – Allows the executor of the task to indicate progress as a percentage of the work to be done. Values should be even multiples of ten: 10%, 20%, 30%, etc... When a task is changed to the “done” state the percent complete automatically changes to 100%.
• Priority – Designates the priority of the task relative to other tasks. Priority and End Date can be used in conjunction by a user to determine which tasks should receive attention next. Possible values are: “very high”, “high”, “average”, “low”, and “very low”. The default in most user interfaces will be “average”. Overuse of priorities like “very high” and “high” over time will deteriorate their significance. Site administrators are encouraged to draft a policy which can be used by users to select an appropriate priority for tasks. If in doubt, leave the priority of a task as “average”.
  Accounting Information – This is a free-form text field used to describe the relationship of the task to the business or billing system. While provided in a variety of user-interfaces it is advised that this field be left blank as it is primarily of used to automated processes.
• Associated Companies / Associated Contacts – These fields are provided solely for compatibility with Microsoft Outlook. While provided in a variety of user-interfaces outside of Microsoft Outlook it is adviced that they be left blank. If Microsoft Outlook encounters values in these fields that it cannot understand undefined behavior may occur.
  Sensitivity – Used to indicate how data related to the task should be handled. Possible values are “normal”, “personal”, “private”, and “confidential”. How this value relates to how the task is actually handled is determined entirely by the policy of the site.
• Notify Creator (Notification) – This value determines when the creator of the task will be notified via e-mail when an action has been performed on their task. Possible values are: “never”, “always”, and “accept / done”. If the value is “never” the creator will receive no e-mails regarding the status of the task. If the value is “always” the creator will receive an e-mail for every event performed on the task, including comments. The value of “accept / done” indicates that an e-mail should only be produced then the task is initially accepted by the executor and when the task's status is changed to “done”.
  Due to limitations in the Document API this value is not available via the legacy XML-RPC service. It is however provided as the “notification” attribute of the “Task” entity via the zOGI XML-RPC API provided via ZideStore.
• Actual Work / Total Work – Actual work and total work are used primarily in the context of tasks with billable time. Total work is intended to contain the estimated amount of time, in minutes, that completion of the task will consume. Actual work is expected to contain the amount of time actually spent of the task. With these two fields both a simple billing mechanism can be constructed and reporting on the accuracy of estimated time can be performed.
  • These fields correspond directly to the “Actual Work” and “Total Work” fields of a Microsoft Outlook task when using the ZideLook Outlook connector.
• Travel Kilometers – Used to record any travel related to the completion of the task, this value is expected to be in kilometers.
  Project – Designates the project the task is assigned to, if any. A task can be assigned to either one or no projects.
• Executor - The current of the task; some places in the WebUI or other clients may refer to this value as “Owner”. It is important not to confuse this with the owner of the task – the term “executor” is the preferred name for this value. The executor may be either an account or a team. When creating a new task a “notify” check box is normally provided, if notify is checked then an e-mail is dispatched notifying the account or team that a new task has been created that is assigned to them.
• Owner – The owner of the task. Except where the help-desk role is in use this will always be the same as the creator. In most cases when a user interface displays the owner of the task it is actually referring to the executor of the task.
• Comment – A long form description of the task. This value should completely describe the task to be performed. A comment may contain line break, paragraphs, etc...

Outlook attributes

Several of the attributes available in the task object exist for compatibility with Microsoft's Outlook client, which can be used via the commercial ZideLook plugin. These attributes are: “Associated Contacts”, “Associated Companies”, “Accounting Information”, “Sensitivity”, “Actual Work”, “Total Work”, and “Travel Kilometers”.

Task lists

Most applications, including the WebUI, present tasks in three lists: to-do, delegated, and archived. The archived and delegated lists are quite simple. The archived list consists of all the tasks owner by the user that are presently in an archived state1. The delegated task lists contains all the tasks owned by the user which are not archived and for which the user is not currently the executor2; note that a task on a user's delegated tasks list may be delegated to a team of which the user is a member – in this case the task will potentially appear on both the user's to-do and delegated lists.

The to-do list is a more complicated construct. Internally the to-list contains all jobs which: are not archived, the user is the executor or where the executor is a team of which the user is a member, and either the job is not in a done state, or if the user is the owner of the job3. In most cases however the to-do list is additionally filtered in some fashion by the front-end application. For instance the “Teamtasks” checkbox in the WebUI which enables the user to determine if they wish to see tasks delegated to teams of which they are a member or only tasks of which they already the executor. This filtering of the tasks is the sole responsibility of the client application.

Customization

Preferred Executant

The preferred executant feature is enabled by setting the “JobPreferredExecutantsEnabled” to YES in the ogo-webui defaults domain. When the owner of a new task is a team this feature allows multiple accounts from the selected team to be selected as “preferred executants”. When an account is selected as a preferred executant the task will appear in the user's “assigned tasks” list. In the web interface the “assigned tasks” tab only appears in the task application if this feature is enabled.

This functionality is useful if there are one or a few people on the specified team more appropriate for a given task than others, this can help avoid the creation of a myriad number of teams.

This feature makes use of the object linking functionality of the OpenGroupware server. Internally the preferred executants of a task are indicated by the creation of an object link of type “Preferred Job Executant” with the job as the source of the link and the executant1 as the target of the link. The user will be able to see this link in the task's “link” tab and the link can be deleted by clicking on the provided deletion icon. The task log will record the creation of the preferred executant link with a message like: “Add job link to Smith, Fred (fred) [team:all intranet]”. Deletion of the link via the “link” tab does not record a message in the task's log.

Disabling Object Link Editor

In the OpenGroupware WebUI the presence of the links tab can be disabled via the “OGoTaskLinksEnabled” default. If not set or set to a value of “YES” the links tab will be displayed when viewing a task. If set to a value of “NO” the links tab will not be displayed. This only effects if the links are displayed in the WebUI; it does not effect the ability to create or remove object links via other means such as the legacy or zOGI XML-RPC APIs.

The Help Desk Role

The help-desk role may be assigned to a team using the “OGoHelpDeskRoleName” default; the value of this default should be the name of the team. When this role is enabled all members of that team will be able to create tasks with the owner as any other user known to the server. The user who creates such a task will still be recorded as the creator, only the value of the ownership is effected.

A use-case for this feature might be a problem help desk where users call in to report problems and the help desk operator determines the nature of the problem, creates the task, and dispatches it to the appropriate user or team. That task will then appear on the callers, not the help desk operators, delegated tasks lists. Further actions on the task notify the owner and the executor directly, the help desk operators involvement with the task ends once it is created.

Currently the help-desk role is only useful from a zOGI API client; GroupDAV and the WebUI do not support setting an alternative owner for a task.