Version 1.22.3
This version further extends the ESM platform tool set with new tables to manage company Demands, Purchases, Budgets, Costs, and product records. Another new feature is tabulation settings for the table forms. Various improvements include: the Summary widget, indications, page views for the portal, and email notifications. Besides, there are some system updates that enhance the platform performance.
New features
Form tabulation setting
You can set the tabulation on the table record forms. Configure the most comfortable and convenient methods to navigate between the form elements with the keyboard. For more information on the new settings, read the Form Layout article.
New tables
Product – a new table designed for storing the company's products. The product records contain data on the resources for which the product is a configuration. They include employees, technologies, partners, and suppliers. Users with the new roles product_agent and product_manager can create and manage the product records.
Financial tables – the new tables that Demands, Budget control, and Purchases are based on. Financial tables are also involved in managing actual costs related to specific cost centers.
The new tables are extendable and will be of use in the future versions of the ITAM and SDLC applications.
Find more information in the Platform Service Tools section:
| Documentation section | Table |
|---|---|
| Product |
|
| Demands |
|
| Purchases |
|
| Budgets |
|
| Actual Cost Items |
|
| Cost Category |
|
| Cost Centers |
|
| Currencies |
|
| Fiscal Periods |
|
System improvements
Indications
Now, when the Active checkbox is cleared or the indicator is deleted, the system notifies you that the active related indications will be canceled. The active indications are canceled after the user confirms the action. When deactivating or deleting an indicator, the Updated at field on the related indications form displays the time the indication was canceled. Find more information in the Indications article.
The Summary widget
The Summary widget on the approval form now displays only completed fields. To display the widget on the portal, ensure that the Default form view is created in the target record. If it is not set up, configure it. Read more about the widget in the documentation.
Updates on the record forms
On the Configuration Items table form, the following fields with the CMDB model attributes have been removed:
- Power
- Information system
- DNS
- IP Address
The demo data local pack has been updated accordingly. It also includes the following changes:
- The warranty and manufacturer_warranty REM attributes have been removed from the demo data local pack.
- Users with the admin role have been granted access for editing the Generate Name for CI (
record/sys_business_rule/163914487417347092) business rule.
In the Related lists area, the Edit button has been hidden from the users who do not have access to edit the record. The changes include the record forms of the following tables:
- Request Model (sys_rmc_model)
- Collections (sys_re_collection)
- Models (sys_re_model)
- Form Views (sys_ui_form)
- Form Section Elements (sys_ui_form_section)
- List Views (sys_ui_list)
Notifications
Email notifications on the inbox approval tickets now include the list of all approvers assigned to the task. The list is divided into two groups – main and optional approvers. So, the users can see their role in the approval request and the roles of other task approvers.
Portal
On the portal, the performance of the side menu widgets and service catalog categories has been improved as follows:
- 7 new attributes are added to the portal Simple tag <sidemenu>.
- a new Fixed header checkbox is added to the Portal form. Use it to fix the header on the page.
- the Ignore ACL checkbox is added on the Portal node form. When the checkbox is selected, the access control limitations set for the records that the nodes refer to are ignored. As a result, the only remaining access limitations are the ones set as filters and user criteria created for the categories and elements of the request model catalogs.
We strongly recommend to check the availability and performance of s_form direct calls from child to parent form before upgrading to 1.22.3.
We implemented isolation of the client script execution context for the s_form object, in cases when forms of several different records that utilize the widgets with the <form> or <remform> SimpleTags are located on the same page. Now, the client script strictly operates the s_form variable related to the form for which it was run. This allows client scripts of different forms to work independently, without random triggering of the "neighboring" forms.
-
On a page with a loaded form, you cannot access the form directly through the s_form variable in the browser console.
-
If on the page with a record form for one table there is an RE model for a record of another table, which is added to the form using a widget with the SimpleTag [<rem>](/platform/developer-help/developer-api/widget- api/simpletags/common-simpletags/rem), or the model is displayed using the <remform> tag, the REM client script will not be able to access the form directly through the s_form variable. In this case, there are two independent form objects on the page.
To operate the form in both cases described above, use the construction s_widgets.getForm('formName'), where formName is the name of the required form view.
System optimization
There are new tools for monitoring the system instances and request tracing, including the following:
- distributed tracing for the Queue Consumer and Schedule Job.
- monitoring for the quantity of the php-fpm handlers (BACKEND_API_MAX_CHILDREN – backend-api) on the cloud instances. This will prevent the instances from crashing due to a lack of handlers.
- an integration tool for OpenTelemetry and Jaeger to trace requests, analyze the application behavior and reveal the problems related to the on-premise instances performance.
- environment variables and a ready replica connection to upload the master database.
Fixes
DEF0018978: PUT requests for the Service Requests table took significant amounts of time to be processed. Now it takes less than one second to process requests.
DEF0018781: There were errors that prevented successful upgrading the platform from versions 1.19.1 and 1.20.1 to 1.21.3 and above. Now upgrading to a newer version goes without any issues.
DEF00187686: Meta data was displayed on the page if there was no preset formatting. The page displayed a list of errors. Now the page displays an error message.
DEF0018747: There was an error that led to an increased load and system degradation due to the monitoring of the quantity of the php-fpm handlers.
DEF0018730: Removing an Indicator (sys_indicator) caused a long-time recalculation of the Indication (sys_indication). Now the recalculation takes less than a second.
DEF0018436: There were repetitive executions of the same blocks of the workflow. Now the workflow context is blocked when initialized, so another request (for example, from the queue) cannot execute the context again.
DEF0018383: The incorrect port number for the microservice DelayQueue has been corrected in the haproxy for the on-premise instances.
DEF0017778: When the records of the Scheduled Imports and Scheduled Scripts tables were deleted successfully, the schedule-job service response was incorrect and in the Exception Logs table there was an error message GRPC server SCHEDULE_JOB_IMPORT_COMMAND returns code 0 with error: .. was displayed in the Exception Logs table. Now error messages do not appear when the records are deleted.
DEF0017660: It was possible to use a URL with different protocols in the SimpleRestRequest method. Now the URLs are verified and only the ones with the http and https are allowed. In case of verification failure, you will receive an error message. The protocol restrictions are described in the Developer API section and Scripted REST API article.
DEF0017646: The s_form.getValue() method returned undefined after the user edited the filter of the related list but did not reload the page. This jeopardized the functioning of the s_form.save(), s_form.getValue(), and s_form.getAllFields() methods addressing the s_form.getValue() method.
DEF0017493: A fix for the issue that caused the monolith-source connector to fail when a column A was created and added to the form of a table, then the column record was deleted, and another column with the same name but another type was created for the same table.
DEF0017462: An error occurred when connecting to IMAP server on port 143. It caused the application to attempt to mistakenly establish a secure connection. Now connection to the mail server on port 143 is performed without using the SSL and TLS.
DEF0017130: Attempting to create a quick response for a table with numerous records resulted in a 500 error. Now the problem has been fixed, and quick responses can be created for tables with any number of records.
DEF0017607: After migration, when running scheduled scripts, an error occurred in the schedule-job-sink connector due to irrelevance of process_id and proccess_at fields and lack of source connector parameter column.exclude.list. Now, an attribute that excludes these fields has been added to schedule-job-sink. This allows scheduled scripts to run without errors.
DEF0016960,DEF0016799: After the execution of the workflow actions, REM attributes and field values for a record that had an active workflow context were often reset. This occurred when other users of the system as a result of a simultaneously interacted with the record by other users or the system. There was a dirty-attribute mechanism implemented, and no data resetting occurs when the same record is updated by multiple scripts at once. Now, after the workflow is executed, the specified REM attributes retain their new value, and only the attributes that have been changed are updated in the database.
DEF0016845: The issue that caused the addQuery() method with the ISEMPTY and ISNOTEMPTY operators to return irrelevant data is solved. The documentation is updated with the information regarding the only two parameters that can be used in this method in server and client scripts. The first one is the field name and the second one is the operator. Also, a list of operators used without the values including ISEMPTY and ISNOTEMPTY is added.
DEF0014868: Users with the admin role could not use all configurations of the reports as they had no read access to the records of the List Views and System Colors tables. Now, with the access granted, the users can use full functionality of the reports on the platform.