•It is now possible to define locked areas—specific regions where the system will not automatically process locate requests. Instead, an internal agent must first review the request in the Locator Cockpit. Processing will only continue after the agent has manually approved it.
•The order book now includes a quick filter, making it easier to filter the list of previous locate requests. This applies to both the Locator Web Client and the Locator Cockpit.
•Users can now update their account metadata directly in the locator web client through self-service.
•UI/UX improvements in the request form of the Locator Client
•The title tag of the Locator Client and Locator Cockpit has been improved. By default, it now displays the title of the underlying Web App. This makes it easier to distinguish between the Locator Client and Locator Cockpit when both are open in parallel browser tabs.
•You can now use a UTM Basemap in the Locator Client and Locator Cockpit. Previously, this caused issues during the map sheet calculation.
As of now, the Spatial Reference used in the WebMap that is used by the Locator Client will also be applied to the PDF printouts. While future releases will decouple this behavior, please note that it still applies in this release.
•You can now reference Kubernetes Secrets in the `values.yaml` file storing sensitive data in plain text directly within the values file.
•The Solution Package is now available in the VertiGIS Container Registry, and can be downloaded via ORAS. For more information, check the What's included section.
•The file upload endpoint has been enhanced with additional security checks. You can now configure a whitelist of allowed file types, ensuring that only these specified types can be uploaded.
•Additionally, an optional antivirus check can be configured using the open-source antivirus engine ClamAV.
•Upgraded to Quarkus 3.15.3.
•Refer to the VertiGIS Changelog for a complete list of bugs fixed in this version.
Please make sure to read the upgrade instructions for this release.
•Fixed an issue that prevented the Process Manager container from starting correctly when an unfederated ArcGIS Server was referenced in the configuration.
•We Introduced the Cockpit App a dedicated application for searching and retrieving locate requests from the database. This app is meant to be used by internal employees of the utility to search within the request database.
•Added support for resending historical requests in the orderbook.
•Introduced a quick filter for faster and easier access to previous locate requests.
•Introduced separation of internal realm (used for Admin Client, Cockpit App, Kubernetes Dashboard) and external realm (user for Network Locator Client) for security reasons.
•Upgraded to VertiGIS Studio Web 5.33 and VertiGIS Studio Workflow 5.42
•Upgraded to KeyCloak 26.0
•Updated base libraries to improve performance and security.
•Added the option to deploy the Kubernetes Dashboard web application to the Kubernetes cluster as an optional feature. The Kubernetes Dashboard provides a user-friendly interface for monitoring and managing the cluster, allowing users to view resource usage, troubleshoot issues, and manage workloads such as pods, deployments, and services. This can be particularly useful if you do not have another Kubernetes monitoring tool in place. However, if you already use a monitoring tool, deploying this dashboard is not necessary.
•We introduced a new landing page as the starting point for the Network Locator WebApp. Users will now begin their journey here. The page can be customized using standard Keycloak theming techniques to align with corporate design guidelines.
•Starting with this version, the user authentication is done directly against the Network Locator User Management (KeyCloak). Additional Esri Named User for every user is not required anymore.
•We further refined our Helm charts to simplify the deployment process on Kubernetes clusters, ensuring an even smoother deployment experience.
•Version 1.0 is the initial release of Network Locator, providing basic locate request processing capabilities. This version is fully cloud-based, with web services running exclusively in a Kubernetes cluster.