5.3 Actions required when upgrading Ops I version

The following tasks need to be performed in conjunction with the Ops I upgrade.

(Table) Tasks required when upgrading Ops I

Item Conditions requiring action
Preserving the customized Ops I features When upgrading from v02-50 to v02-70, or from v02-70 to later versions
When upgrading from v02-90 or later
Changing the ticket notification function When upgrading from v02-50 to v02-70 or later
  • If you want to change the notification function from the notification function using the mail server set in v02-50 to the notification function in Ops I
Updating the AWX execution environment When upgrading from v02-50 to v02-70 or later
Displaying knowledge articles When upgrading from v02-70 or earlier to v02-80 or later
  • If you created knowledge article categories before the upgrade, and you want to display knowledge articles belonging to those categories in the knowledge application after the upgrade
Adding notification object fields When upgrading from v02-80 or earlier to v02-90 or later
  • If a task name configured before the upgrade and a field name to be added are defined with the same name
Changing the notification email address When upgrading from v02-80 or earlier to v02-90 or later
Modifying definitions due to the Material UI upgrade When upgrading from v02-80 or earlier to v02-90 or later
  • If you created a custom script and are using "setSelectedIds" in that custom script


[Changing the ticket notification function]

Ops I provides the following ticket notification functions.

  • Ops I notification function: Supported in Ops I v02-70 and later
  • Notification function using mail server: Supported in Ops I v02-00 and later

For details, see “Ticket notification function”.

The following actions are required when upgrading Ops I.

(Table) Ticket notification tasks to be performed when introducing or upgrading Ops I

Ops I version Action
When upgrading from v02-50 to v02-70 If notification settings are not configured in v02-50, the Ops I notification function will be set automatically. If you have configured the notification function using a mail server in v02-50, those settings will remain unchanged. Additional tasks are required only if you wish to change the notification settings.

For details on setting the notification method, see “Use Cases > Use cases for notifications and email-based ticket creation” in the “JP1 Cloud Service/Operations Integration User’s Guide (ITSM Operation Manual)”.



[Displaying knowledge articles]

In Ops I, the following access controls can be applied to knowledge articles and categories:

  • Validity of knowledge articles (show/hide in the knowledge application)
  • State Management knowledge articles (public/private for customer users and requester users)
  • Validity of categories (show/hide in the knowledge application)
  • Category separation by customer
  • Category separation by group

See “Access control of knowledge articles” for details.

Category separation by customer and by group are functions available from v02-80 onward, and when Ops I is upgraded from v02-70 or earlier to v02-80 or later, these settings are not applied. To prevent knowledge articles from being displayed to unintended users, categories created before the upgrade and set to “[invalid] (show)” are automatically changed to “[invalid-temporarily] (hide)” at the time of upgrade. The Validity status and State Management of knowledge articles are carried over from before the upgrade.

When upgrading Ops I from v02-70 or earlier to v02-80 or later, the following actions are required.

(Table) Knowledge management tasks to perform when upgrading Ops I

Ops I version Action
Upgrading from v02-70 or earlier to v02-80 or later As necessary, perform customer separation and group separation of categories, and change the settings of the categories to which the knowledge articles you want to publish belong to "[invalid] (show)".

For how to enable (display) categories, see “[FAQ] > [Category Management]” in the “JP1 Cloud Service/Operations Integration User’s Guide (ITSM Operation Manual)”.



[Adding notification object fields]

The notification object field “workflow.Any task name” allows you to specify any schedule that belongs to a workflow. If a task name in a schedule configured before v02-80 conflicts with a field name added in v02-90, the “schedule” object might not be displayed correctly. For details about notification object fields, see “(Table) Object fields that can be used in Notification”.

Take the following actions:

  • Before the upgrade:
    Check the Notification YAML definition to ensure that no field names match task names specified by "workflow.Any task name".
  • After the upgrade:
    If any task names specified by "workflow.Any task name" conflict with field names, change them to "workflow.schedule.Any task name".


[Changing the notification email address]

When upgrading from v02-80 or earlier to v02-90 or later, perform the following steps.

(Table) Procedures for changing the sender email address when upgrading Ops I

Ops I version Conditions requiring action Action
Upgrading from v02-80 or earlier to v02-90 or later Required. Perform an operation that triggers an email notification, such as resetting a user's password from the login window using any user account, and verify that the email is received.
Perform this procedure if email is specified as the notification method in the notification settings. In the Notifier YAML file, change the sender (from) address specified as "noreply.opsi@itg.hitachi.co.jp" to "noreply@ops-integration.com". Also, after changing the email address, verify that emails sent by the notification function can be received. For details about the YAML file, see "Notification, Notifier".
Perform this procedure if you are using an action that sends email in a workflow. In the "core.sendmail" section of the workflow YAML file, change the sender (from) address specified as "noreply.opsi@itg.hitachi.co.jp" to "noreply@ops-integration.com". Also, after changing the email address, verify that emails sent by the workflow action can be received. For details about YAML files, see "Workflow".
If emails are not received after the sender email address is changed, check whether there are any issues with your filtering settings. For details, see "Notes on e-mail notifications from Ops I".
NoteTips
You can change the email addresses specified in the Notifier and Workflow YAML files even before upgrading. Follow the same procedure when making changes before the upgrade.


[Changes to definitions due to the Material UI upgrade]

Implement the following changes in response to specification updates to the Material UI used by Ops I.

■ Verification and modification of custom scripts due to changes in OITable.setSelectedIds behavior

To accommodate changes in Material UI specifications, when the row selection state of a Table component is changed by “OITable.setSelectedIds”, the change is now detected and the “handleSelectionModelChange” method configured for the same Table component is executed.
As a result, if “OITable.setSelectedIds” is called within the “handleSelectionModelChange” method in your custom script, an infinite loop will occur when a row in the Table component is selected.
To avoid this issue, modify the script, for example, by removing the call to “OITable.setSelectedIds” from “handleSelectionModelChange”.

  • How to verify:
    Check the custom script to ensure that "setSelectedIds" is not called from "handleSelectionModelChange".
  • Solution:
    Modify the custom script so that "handleSelectionModelChange" does not call "setSelectedIds".

Section structure

5.3.1 Preserving the customized Ops I features
5.3.2 Updating the AWX execution environment