Accounts can be reactivated in Octopus in relation to their status in Active Directory with the /ReactivateUsers parameter. For more information, consult the ADSIReader article.

The Number of attachments column gives the sum of the attachments from the request and the activities, but excludes the ones contained in tasks. 

The Web portal can process and display date and time values entered by the end user according to each user's respective time zone (for example, through a reservation or with the opening time of a request). 

To use the time zone function, you can assign a default time zone through the Options menu, a time zone to each of your sites in the Reference Data Management or even a time zone per user, specified in their profile. 

Please refer to the TimeZones article to learn more about this new feature.

 

An option allows displaying a link Access the Web Portal that redirects to the authentication page located on your Intranet when the error message that the portal cannot be access directly gets displayed. Furthermore, the link will also work when an assignee accesses the Web portal through the Tools > Launch the Web Portal menu. Contact us toactivate this option.

Exporting to Excel with Time fields (resolution delay, response delay, breach, etc.) will present complete data which can be manipulated using formulas and calculations in Excel instead of getting rounded up 15 minutes blocks like it used to be.

It is possible to specify an access path to an ADSIReader fields correspondence file using the parameter /MappingsFilePath. For additional information, please see the ADSIReader article.

It is possible to configure MailIntegration to ignore specified attached files. Please refer to MailIntegration articleto learn more about this feature.

When converting an SR to an incident, you can now select the incident template and fill in the custom fields configured in the form linked to that template.

In order to increase the quality of the information written in requests by technicians, filling the form can be made mandatory. When selecting an incident template or SR type with a form marked as required, a message will appear to invite the technician to fill-in the form.

Saving the request without completing the information will not be possible. This also fixes the previous limitation that prevented SR types containing conditional tasks to be used from the Windows client.

To make a form mandatory, check the Form required checkbox within the Form configuration tab. Refer to the WebForm Customization article to know more.

To display a sub-list as a main list in a new tab, use the Open list in tab action from the contextual menu.

If the Note field of a CI contains information related to the completion of requests, you can activate the display of this note in the request detail screen.

Contactus to have the option enabled.

Normally, if an activity has more than one recipient, each recipient will receive an email without knowing who else has received it (blind carbon copy). A new option named Send single email to all recipient, located in the communication section of the activity will send an email without hiding the recipients. This allows recipients to know who was notified, and to use the Reply to all feature of their email client.

The options controlling which requests a user can see on the Web Portal now allow multiple sites or departments, instead of only one.

A new option allows the to use both the Query String and the Username, Password types combined. If the user id passed in the URL is not recognized, then the system will present the normal login screen prompting the user for a username and password. Contactus to activate this option.

A default value can now be configured for the Date and Time fields in Web forms. For example, you could define an Expected Delivery Date field initialized to 5:00 PM. Thus, if a user sets the date without setting the time, the 5:00 PM time will probably be more usable than the exact moment where the request was submitted (1:23 PM).

Attaching files to a Web Portal request has now changed in the following fashion:

• This applies to either new incident or activities added to already opened requests
• Multiple files can be chosen instead of one at a time
• Files are now transferred asynchronously and are not blocking Web Portal usage
• Files selected will stay if the user is changed on the form
• A limit of 100 MB is set on all attached files simultaneously

The approval activity will now be attributed to the Octopus user who enabled the approval, and not to the original approver.

We can now modify the Username prompt on the Web Portal login page. Contactus if you want to have it changed.

You can now define custom forms for your internal SR types or incident templates. To this end, the form configuration and publication options are now in two separate tabs.

When converting an incident to an SR, you now have a link to display and fill the custom form associated with the selected SR type.

It is now possible to display the CI note when printing an incident. Contact the OctopusServices Desk to activate this option.

• In the condition field of a task, you can now use the F3 hotkey to access the column selection tool
• Customs fields created in Web Forms are now available via the F3 hotkey without having to write them in manually
• The condition field of a task now supports the different from operator (<>) to determine whether a task must be created or not
• Octopus will no longer use tokens present in the subject or description field of tasks to determine whether it must be created or not.

For more details, consult the AdvancedTask Configuration article.

Filtered combo lists now show a message whenever none or than 200 results would be displayed.

From the resulting list of an attached files search, double-clicking on an item will open the relevant request.

Octopus will correctly display in the activity log or detailed fields of a request UNC names having spaces when encapsulated within opening and closing angle brackets (< and >).

• Before : \\server\share having spaces$
• After : <\\server\share having spaces$>

The Access to the requests via the Web Portal options located in the user profiles are now team-specific.  Two new columns have been added to help manage users permissions.

• Access to requests (Department)
• Access to requests (Site)

Attached files can now be sent automatically when the following actions are triggered:

• Task assignation
• Approval task assignation (Request for approval)
• Approval task assignation to an approver pool (Approver required)

To allow attachment, the Include attached files in notifications checkbox is available in standard and approbation tasks.

You can now use the configured custom Web forms while creating and Incident/SR from within the Windows application!

This makes possible to use conditional tasks from within Octopus. When selecting a template with custom fields, the system will display a Form link allowing you to fill out the fields.

 

 

A new Condition field has been added, validating whether or not a task needs to be generated. This new way allows for more powerful cases. For example, the Train Requester task would only be necessary if the user has specified Beginner or Intermediate in the Expertise field. To do that, we would put = Beginner, Intermediate in the condition field.

Refer to the Advanced Task Configuration article to know more.

You can now initialize fields of a Web form based on values related to the requester or user. For example, you could initialize the Phone number to reach you field with the requester's phone number. This way, the requester only has to correct the phone number if required. To do this, you would add the  variable in the Default Value field.

Refer to the WebForm Customization article to know more.

The Create Change action available in the Configuration module will now open the change creation main form. The previous form has been retired. If you have a need to bring back the old form, please reach the OctopusService Desk.

To enhance the visibility of DataImporter failures, they will now be reported in Octopus as Events, the same way MailIntegration failures are.

External Identifier and Active Directory Key are now available in the Users module.

ADSIReader will use these fields to uniquely track accounts in Active Directory.

Use the Option > Clear Active Directory Identifier action to remove the tracking information from the account.

Refer to the ADSIReader – Integration to Active Directory for details on the tracking mechanism between Octopus accounts and Active Directory users.

Octopus now accepts a wider range of responses for the yes or no. The response no longer needs to be alone on the line. 

Examples :

• Yes, thanks!
• No, the budget is too high
• Yes, please charge back to account 26587

When a user display's a request in the Web Portal, the Resolution Date has been added. Moreover, date fields are now also displaying time.

An option now allows displaying of the Resolution Date column in the request list. Contact the OctopusServices Desk to activate this option.

Text fields, like the incident description or the text in an activity, now accept up to 65 000 characters.

A new type of relationship establishes the notion of dependencies between requests. It is possible to specify the request that needs to be completed before taking charge the next request. Setting a dependency will mark as pending the dependent request until all dependencies are resolved. The Dependencies not completed pending reason will be used.

Do not hesitate to contact the OctopusServices Desk if you want to deactivate the pending automation.

A request can have multiple dependencies. You could build a chain of dependency as long as required. When opening a request with unresolved dependency, a yellow notification will appear, showing the list of dependent requests.

Moreover, new columns are now available to manage dependencies:

• Has dependent allows to identify all requests for which another request depends on
• Dependencies lists all dependent requests, and allows to easily open them

 

Fields in Web Forms can now be shown in reaction to entries from previous fields. For example, if the querent marks the "Local administrator rights" checkbox, then you could have the "Justify" field appear. For more information, see the DynamicWeb Forms wiki article. 

Before : The Create and modify an Octopus User permission was required to change any data related to an Octopus user, including any general data (phone extension, department, etc.) 

Now : This permission only controls attributes related to the Octopus account (permissions and preferences), not the general information of the person. To modify general information, the Modify a user is sufficient.

The Create and modify an Octopus User has been renamed to Create and modify an Octopus account to better represent this.

The KPI reports now contain new information:

• Effort by category (for incidents)
• Effort by type (for the SR)
• Effort by resolution group

We've brought changes to facilitate management of inter-request relationships:

• Two new ways of adding relations between requests
  • By specifying multiple request numbers separated by comma
  • By using the magnifying glass to perform an advanced search
• Improvement to the parent-child related incidents
  • A yellow notification will appear at the top a child incident showing the parent's number.
  • By resolving the parent, an activity will be displayed to child incidents.

For more information, refer to the RequestRelationships article.

WebTech now shows the name of the Querent in the requests. 

A new type of field has been added to be used in the Web forms: Date and Time. It is available for your incident templates and SR types and allows to query with additional precision the moment of an event. For example, the date and time of the last good version of a document that you need to restore, or the moment that a failure of an event occurred. 

The date is selected from a calendar and the hour and minutes are selected using scroll bars. Once the information has been entered, it can be modified directly in the field or with the calendar.
 

It is now possible to allow the requestor to specify the due date or the open date of a request. This information would be configured within the Web form with a Date and Time type field combined with the Destination column. 

You can choose between Due date or Open date in the new Destination column and the date and time selected will be added where specified in Octopus. You can add the Open date and a Due date to the same request, but you cannot add two open or due dates. 

Note that the regular rules for these types of dates apply, so you cannot have a future open date or a past due date. 

You can look for attachments from the advanced search. This will allow you to extract data in regards to attached files and requests, users, CIs, etc. from Octopus. 
 

For more information on how you can use advanced searches in Octopus, consult the AdvancedSearch article. 

You no longer need to configure multiple ADSIReader executions if you only want part of your Active Directory structure. You can now use the /Exclude option specifying a text file that contains the OU you want excluded. 

For more information on the parameters, consult the ADSIReader- Integration to Active Directory article. 

Use the /DeactivateUsers parameter to allow ADSIReader to automatically deactivate users from Octopus having an AD account that has been deactivated or deleted or placed in an excluded OU.

For more information on the parameters, consult the ADSIReader- Integration to Active Directory article.

The content of Site and Department reference data can now be used from a Web Portal custom form. When the field type is used, the result of the selection will be copied into the request description. The use of that type will NOT alter the site or department of the request itself

As in the main Octopus application, Web Tech now allows defining the due date for a request. The availability of this field depends on configured options and permissions the Octopus users has (just as in the main Octopus application).

 

You can now show the procedure linked to a template (or an SR Type) from the Incident/SR creation dialog box. After selecting a template/type, the "display the procedure" link will appear if a procedure is associated with it.

This field is now available in the user file and in the My profile section of the Web Portal. This information can be imported from Active Directory or with DataImporter. 

We have added two items to the unavailable users feature:

1. When starting Octopus, you will be prompted to set yourself as available if Octopus detects that you are currently unavailable
2. When selecting the recipients of an activity to be sent by email, the system will indicate if some of the recipients are unavailable. This will allow you to choose if you want to send this activity to the user anyway

ADSIReader can now synchronize Active Directory groups like "Domain Users" in addition to the standard groups (created manually).

The unavailable users feature can be used as much for the end users that can be approvers than for Octopus users that process user requests. To allow the Service Desk to be aware when assignments are given to unavailable users, or if activities are added to requests in the hands of unavailable users, Octopus now has two notifications: 

• Request/Task assigned to an unavailable person
• Addition of an activity to a request/task assigned to an unavailable person

We have improved the parent-child request management to prevent multiple data entries and to concentrate effort on the resolution of the parent:

• The status of the parent is reflected in the children requests
• The Communication section will facilitate communication with all users affected by the outage
• It will be possible to add activities that will be visible in the child requests from the Web Portal 

For more details on the parent-child relationship, see the Parent-childincident behavior of the RequestRelationships wiki. 

It is possible to see the internal procedure of a requests in Octopus. This option helps Octopus users who work on the requests; you can add steps to be followed, troubleshooting information, etc

The information that will be displayed is related with the incident template or the SR type. The Display the procedure action is always visible; it will be grayed out if there is no procedure and visible if there is one.

To find out how to configure internal procedures, see the Howto add an internal procedure section of the BasicConfiguration - Incident wiki

Here is a glimpse of what Spring has in store for Octopus!

When an Octopus user is on vacation or unavailable for many days, we can now change his status to "Unavailable". The Octopus user can change his own status from his user file or another person can do it for him. Follow the steps below to make the modification. 

 

From the user file:

• Go to the User tab, in the bottom left section
• Check the Unavailable field
• Add a Return date (optional, but recommended)

 

From the Web portal: 

• Go to the My profile section 

• Check the Unavailable field

• Add a Return date (optional, but recommended)

 

During his absence, if a person assigns a request to the unavailable Octopus user, the following information will advise them that the person is not available:

In Octopus

• In the assignment field
  • The user's name will be grayed out
  • With the word unavailable or a return date
• The Assignment to an unavailable person notification will be received if
  • You are set to receive this notification
  • You are member of the unavailable user's group
• The Unavailable field is checked in the user's file
  • User tab
  • On the left part below the Notes field
• ​​The Return date is filled (optional)

 

In Web Tech

• In the assignment field

  • The Octopus user's name will appear with the word unavailable or a return date

• The Assignment to an unavailable person notification will be received if

  • You are set to receive this notification

  • You are a member of the unavailable user's group

A couple of small changes were made to facilitate the use of request relationships. 

The detection of multiple incidents will automatically adjust the direction of the relation

In cases where the cardinality between requests is of One to Many, and if more than one incident is selected, the Link action will bring up a window where the proper direction of the relationship will be selected. This will be particularly useful in cases of parent-child relationships. 

A child incident cannot be the parent of another

In order to follow best practices and to make the use of relationships more fluid, Octopus will no longer allow for a parent incident to be the child of another.

Coming soon, a newsletter will be available each season to inform you of important changes, tips and trick and other Octopus news.

In preparation, we have changed the help menu; the Welcome page has been renamed News. Please note that the first newsletter is planned to arrive with Spring. 

Do not forget to read it.

To improve searches done in requests on Web Tech, we added a filter. Octopus looks for the exact or partial expression entered in the field. The search is done on most fields in the request. 

When using ADSIReader to import items from Active Directory, a key is created in Octopus. This key is used to identify the item during subsequent imports. 

This key was not visible before, but it has been added as a column. In case a change to the item has been made, and the key causes a problem, an action has been added to delete it.

The action is found in the Tools > Clear Active Directory identifier menu and it erases the information in the field and will be ready to create a new key at the next import.

When a user adds a resolution activity on behalf of another assignee, the Resolved by column will reflect the name of the tech who did the resolution. To find out if the activity was entered by another person, add the Created by column. 

An activity is automatically added with the user's name when he makes changes to a reservation from the Web Portal. The activity describes the modification made by the user as you can see in the image bellow.

To find out more about this solution, see the ReservationManagement wiki page. 

When an Octopus user is completely deactivated or returned to an end user status, he now stays available as a search criteria in the advanced search window, under the Inactive users. 

 

The search for solutions will now only return problems with a documented know error that is still without a permanent solution. 

The Octopus spell check function is now available from a remote desktop connection.

We have made changes to the use of request relationships in order to make it simpler:

• There are two new methods to easily add relationships
  • By separating the request numbers with a coma
  • By using the magnifier to do an advanced search
• Improvements to the parent-child incident type
  • A strip at the top of the screen in the child incident indicates the parent number
  • At the resolution of the parent, an activity is visible in the child incident

For more information, see the wiki on requestrelationships. 

You can now link together requests of all types (by example, you can link an incident to a change). In addition, when you link two requests, you are prompted to specify the nature of the relationship (is related to, is the solution of, etc.) as it is the case with the relationships established between two CIs. 

Impacts of this change: Some Octopus windows were specifically managing some relationship types. By example, in a Problem record, Caused by change and Solution change were fields allowing a link between a problem and a change; these fields have been eliminated and became real relationships. Throughout Octopus, all different types of relationship have been harmonized and consolidated in the Requests tab.

Here are examples of relationships that you can set:

• Is related to
• Is created from
• Is the parent of a same incident
• Is the child of a same incident
• Is an occurrence of
• Has for occurrence
• Is the cause of
• Has for cause
• etc.

After numerous votes on our forum, you will notice that the addition of activities now uses a non-blocking window, which means that you can view other requests and copy-paste information before completing the activity. Also, the Add activity window can be maximized (or minimized).

There are tow new choices in the Default View list

1. Previous session tabs
   • When Octopus is closed, the layout of open tabs is saved. At the next startup of Octopus, the tabs will be present. (Very popular request on the Octopus forum)
2. Fixed tabs
   • When Octopus is closed, only the layout of fixed tabs are saved.. At the next startup of Octopus, the tabs will be present

It is possible to add members of an Octopus or user group as the recipient when sending an activity by email

1. Select the Group... option
2. Choose the user group (top section) of the Octopus users group (bottom section)

New type of task that allows to send an email notification within the execution of a request. 

1. When creating the task, select the Notification type
2. Enter the recipient of the email
   • Requester
   • Technician
   • User
   • All users
   • Supplier contact
   • Group
   • Other user
   • Other email
3. Enter dependencies if required
4. Select the options
5. Enter the subject of the task
   • Required field
6. Enter the task description
   • Required field

 

 

We have often found that the categorization done at the beginning of an incident was not reviewed at resolution and this can cause the reports to be biased, since the categorization can change as the incident is analyzed.

In order to improve Octopus best practices and aligned with ITIL concepts, a new option allows to review the categorization and subcategorization directly in the incident resolution window.

A new permission was added to the Event Management module 

• Modify an event

It is now possible for Octopus to connect to your central authentication system to facilitate access to the application.

Unique authentication can cover:

• Web portal for users
• Octopus software for Octopus users (technicians)
• Both the Web portal and the software

To implement the integrated authentication, you must first have a federation infrastructure that meets the following requirements:

• The introduction of Active Directory Federation Services
• Setting up a proxy server in your federation, visible on the Web
• A recognized SSL certificate

The possible configurations of Active Directory being endless, Octopus cannot commit to provide support for the implementation of those requirements; you must ensure that you have internal resources with the necessary technical knowledge. 

For more information, see the following wiki article: Unique authentication with ADFS 

It is now possible to modify the default request type selected in the creation form of a new request in Octopus.
 
This option can be configured in Tools - Options