General vulnerabilities ▪Eliminating the use of the HTTP_X_FORWARDED_HOST header from PHP resources to avoid exploring the vulnerability known as Host Header Attack; ▪Eliminating the use of the unserialize() native function from PHP resources exposed to parameter manipulation by the user to avoid exploring the vulnerability known as PHP Object Injection; ▪Implementing improvements in the session validation of PHP resources to avoid unauthorized accesses; ▪Removing the use of an old third-party PHP library named XAJAX, which was outdated and vulnerable to XSS. |
Previously, when exporting the listing of a view screen to Excel, such as Document (DC021) or Project (PR020) view, the date fields would count as text values instead of date values. They would even be formatted correctly as a date, but they would be aligned to the left as regular text, and the resulting value would be seen as text or number when performing some operations, requiring the user to perform additional formatting to turn it into a conventional date.
For example:
If certain field has the date value “10/01/2020” (dd-mm-yyyy) and it truly is of the date type, when adding two days to this value, the new value “12/01/2020” (dd-mm-yyyy) is obtained already in the conventional date format.
However, if this same field has the date value "10/01/2020" (dd-mm-yyyy), but it is not of the date type (e.g.: it is common text), by adding 2 days, the obtained value would be "43842"; therefore, it is necessary to use another function or format to turn this numeric value into the date "12/01/2020" (dd-mm-yyyy).
This is only an example, which may or may not be applicable depending on the Excel version being used.
To avoid additional manipulation or treatment to these date values, from this version onwards, when exporting the view screen tables to Excel, the date values will be exported in a date format recognized by Excel to facilitate the handling of these fields.
See an example of how the field was exported previously: |
And how the field is exported from this version onwards: |
It was a date, but it would be interpreted as a text, aligned to the left |
Now it is interpreted as a date, aligned to the right and not needing additional treatment. |
According to Microsoft, the Microsoft 365 (previously Office 365) applications and services will no longer support Internet Explorer 11 from August 17, 2021 onwards.
Although IE 11 will continue to exist and have support as a component of the Windows operating system, SE Suite will follow the Microsoft 365 guidelines not to provide further support to IE 11 from version 2.1.5 onwards, in order to prioritize more modern browsers such as Google Chrome (which is already supported) and Microsoft Edge.
It is also worth noting that Microsoft will stop supporting Microsoft Edge Legacy on March 09, 2021. After this date, it will no longer receive security updates.
Microsoft recommends using the "new Microsoft Edge", which is based in the open-code project "Chromium", and they have announced that future Windows updates must already install this new application automatically.
Reference: ▪https://docs.microsoft.com/en-us/lifecycle/announcements/m365-ie11-microsoft-edge-legacy |
In previous versions, when a method was enabled in a data source, it could no longer be deleted afterwards due to product limitations. From this version onwards, it will be possible to remove Web Service data sources even if they have methods enabled; however, for this to be possible, they cannot be used in other SE Suite components, such as Process and Form.
Relevant performance improvements
In this version, we have worked hard to improve the performance of the search service, decreasing the number of requests made for it and the volume of trafficked data. We have optimized the application for it to maintain the records indexed and updated in the search service, requiring less service processing cost.
Until the current version, the SE Suite job queue worked with 2 threads for low priority services and 10 for high priority services. After analyzing customer environments, we have decided to refine this sorting, changing the behavior of the queue to simultaneously process 4 low priority items and 8 high priority items. Thus, the performance and the flow of the job queue will be more efficient.
From version 2.1.4 onwards, the processing of user tasks will be more intelligent and efficient. In this version, we have worked to drastically decrease the number of times in which the user task processing is performed unnecessarily. We have created an intelligence to only process and update the tasks that each user has and commonly uses. Thus, we expect to obtain a good performance gain, stability and database and application server resource economy result.
We have improved the performance of user import webservices, allowing user loads performed through integrations to be faster.
View also the improvements made to this component in previous versions: