Falcon LogScale 1.74.0 Preview (2023-01-24)
|Version||Type||Release Date||End of Support||Upgrades From||JDK Compatibility||Data Migration||Config. Changes|
Bug fixes and updates.
Improvements, new features and functionality
Changes have been made for the three-dot menu (⋮) used for Field Interactions:
It is now available from the Fields Panel and the Inspection Panel, see Searching for Data.
Keyboard navigation has been improved.
For field interactions with live queries, the Fields Panel flyout will now display a fixed list of top values, keeping the values from the point in time when the menu was opened.
Automation and Alerts
The list of Message Templates and Variables is no longer shown in the User Interface when editing Actions, instead a link to the documentation has been added.
A new environment configuration variable
GLOB_ALLOW_LIST_EMAIL_ACTIONSis introduced. It enables cluster-wide blocking of recipients of Action Type: Email actions that are not in the provided allow list.
When creating a new group you now have to add the group and add permissions for it in the same multi step dialog.
Fixed an issue where the dashboard page would freeze when the value of a dashboard parameter was changed.
We have fixed tooltips in the query editor, which were hidden by other elements in the UI.
Fixed an issue where the environment variable
OIDC_USE_HTTP_PROXYwas not respected. It means that LogScale will now call all OIDC endpoints directly without going through the HTTP Proxy, when
OIDC_USE_HTTP_PROXYis set to
This fixes the known issue previously reported in Falcon LogScale 1.63.1 Stable (2022-11-14), Falcon LogScale 1.63.2 Stable (2022-11-30), Falcon LogScale 1.63.3 Stable (2022-12-21) and Falcon LogScale 1.70.0 Stable (2023-01-16).
Some restrictions have been introduced when running with
Starting on a machine that already has multiple users will not delete them, but you will be unable to create additional users.
AUTHENTICATION_METHOD=single-userwith multiple users will pick the best candidate based on username and privilege.
We have set a maximum number of events that we will parse under a single timeout so large batches are allowed to take longer. If you've seen parsers time out not because the parser is actually slow but because you were processing many events in a single batch, this change should cause that stop happening. Only parsers that are genuinely slow should now time out.