Grasshopper 3.24.35 Release Notes
Features
Coverage Map Enhancement – Hide Inactive Regions Overview
To improve usability and clarity when working with regional coverage, the Coverage Map has been enhanced to exclude inactive regions from the displayed region list. This ensures users can focus only on active, operational regions without unnecessary visual clutter.
Key Enhancements
1. Inactive Regions Filtered from Coverage Map
Regions marked as inactive in Region Configuration are no longer displayed in the Coverage Map region list.
2. Improved Map Clarity and Usability
By showing only active regions, the Coverage Map is cleaner and easier to navigate, making it simpler to view, manage, and analyze coverage areas.
3. Consistent Behavior with Region Status
Coverage Map visibility now accurately reflects region activation status, ensuring inactive regions do not appear in operational workflows.
4. Requires a server restart
Tag-Along Enhancement – Restrict Receiving Hours on Follower Orders
Overview
To ensure consistent scheduling behavior for tag-along deliveries, the system has been enhanced to prevent receiving-hour constraints on tag-along follower orders. Since follower orders inherit the delivery date and time from the master order, receiving hours must be defined only at the master level.
Key Enhancements
1. Receiving Hours Restricted for Tag-Along Followers
The system no longer allows receiving hours to be added to tag-along follower orders across UI, Import, and API.
2. Validation on Tag-Along Assignment
When an order with receiving hours is added as a tag-along follower, the operation is blocked to prevent conflicting constraints.
3. Clear User Feedback
Users will receive the following message when this validation is triggered: “Tag-along follower orders cannot have receiving hours. Please move these constraints to the master order and try again.”
Orders Enhancement – Requested Delivery Date Visibility
Overview
To improve visibility into customer scheduling requirements, the Orders experience has been enhanced to surface the customer-requested install/delivery date directly in the Orders grid. This removes the need to open individual orders and navigate to additional tabs to view this information.
Key Enhancements
1. New Order Attribute: Requested Delivery Date
A new order-level attribute, requested_delivery_date, has been added to capture the customer-requested install/delivery date.
2. API Support
Orders received through the API with this field populated will automatically store and update the requested delivery date.
3. Orders Grid Column
A new Requested Delivery Date column is now available in the Orders grid for easy visibility across all orders.
4. Export Support
The requested delivery date is now included in order exports, consistent with other order attributes.
Partners Page Enhancement – Updated UI and Improved Usability
Overview
To modernize the Partners experience and improve usability, the Partners list page has been updated with a refreshed look and feel and enhanced grid behavior. This update focuses on improving clarity, navigation, and day-to-day partner management.
Key Enhancements
1. Updated Partners List Experience
The Partners list page has been migrated to the new UI framework, providing a more modern and consistent user experience.
Note: The Partner details screen remains unchanged and continues to use the existing implementation.
2. Partner Status Visibility
A new Status column has been added to the grid, indicating whether a partner is Active or Inactive.
Active partners are selected and displayed by default.
3. Improved Grid Layout
The Address column has been repositioned to appear directly to the right of the Name column for better readability.
4. Enhanced Navigation and Linking
○ Partner names are now underlined and link directly to the Partner details page. ○ Partner URLs are underlined and link directly to the partner’s website.
Smart Insight – RTBS Orders Waiting for Scheduling
Overview
To help users proactively manage scheduling delays, a new Smart Insight has been introduced to highlight orders that are ready to be scheduled but have remained in Ready To Be Scheduled (RTBS) status longer than the expected lead time. This insight helps surface potential bottlenecks and ensures timely scheduling action.
Key Enhancements
1. New Smart Insight Type: RTBS Waiting Orders
A new insight identifies orders in RTBS status that have been waiting longer than a configured time threshold.
2. Clear and Actionable Messaging
The insight is displayed using the new insight container design and includes: ○ Title: RTBS orders waiting for Scheduling
○ Description: You have orders that are ready and waiting for scheduling. Please review and handle asap.
3. Direct Action from Insight
A “Show me the list” button allows users to quickly navigate to the list of affected orders.
4. Insight Configuration
○ Priority: 7
○ Design Reference: GRAS-11020 – New Insight Container
Reporting Enhancement – RTBS Report Enabled for Licensees Overview
The report provides region and sub region level visibility into orders that are ready to be scheduled but have not yet been scheduled, along with the list of available resources (such as manifests) in each region and sub-region to support efficient scheduling decisions.
To expand visibility into scheduling readiness across the network, the RTBS By Region report has been enabled for licensees. Previously available only for VC, this report is now accessible at the carrier level.
Key Enhancements
1. RTBS Report Available for Licensees
The RTBS By Region report is now enabled for all licensees, providing the same insights previously limited to VC.
2. Consistent Report Structure and Metrics
The report maintains the same structure, fields, and behavior as the existing RTBS report, ensuring a consistent experience across all users.
Defect Fixes
Downloaded Labels Not Sorted Correctly by Consignee Name or PO Number
Overview
Clients reported that when downloading labels sorted by consignee name or PO number, the resulting files were not ordered alphabetically as expected. This made it difficult to quickly locate specific labels and required additional manual sorting after download.
Key Fixes
1. Correct PO Number Sorting
Downloaded labels are now correctly sorted in alphabetical order when sorting by PO number.
2. Correct Customer Name Sorting
Downloaded labels are now correctly sorted when sorting by consignee name, based on the customer’s last name in the order.
3. Consistent Sorting Behavior
Sorting behavior in downloaded label files now matches the selected sort option, ensuring predictable and reliable output.
Drivers Able to Access Warehouse Mobile App
Overview
It was identified that driver accounts were able to log in to the Warehouse Mobile App instead of being restricted to the Driver Mobile App. When logged in, drivers could view all routes—including those not assigned to them—and access freight details, creating an access control and data exposure issue.
Key Fixes
1. Driver Access Blocked on Warehouse App
Driver users are now blocked at the server level from logging in to the Warehouse Mobile App.
2. Access Denied Message in Mobile App
When a driver attempts to log in to the Warehouse Mobile App, the following message is displayed:
Title: Warehouse app not available
Content: “Switch to the Driver App, or sign in with a different account.”
3. Enforced App-Level Access Control
Drivers can now access only the Driver Mobile App and are restricted from viewing warehouse routes or freight details not assigned to them.
Bulk Hold Action Not Applying to Multiple Orders Overview
A regression was identified where the Bulk Hold action for orders was not functioning correctly. Users were unable to apply Hold to multiple orders at once and were required to update each order individually, resulting in operational inefficiency.
Key Fixes
1. Bulk Hold Functionality Restored
Users can now select multiple orders and successfully apply the Hold action in a single operation.
2. Immediate Status Update
The Hold status is now correctly and immediately updated for all selected orders.
Adding Orders to an Open Linehaul Manifest Not Published to Partner
Overview
An issue was identified when adding an additional order to an already published linehaul (LH) manifest in a virtual carrier; it was not fully propagated to the partner system. While the update appeared correctly on the originating system (VC), the partner continued to see only the initially published order, leading to data inconsistency between systems.
Key Fixes
1. Manifest Updates Properly Published After Initial Publish
When additional orders are added to an already published LH manifest and saved, the updated manifest is now correctly published to the partner system.
2. Consistent Manifest Contents Across Systems
The manifest now consistently includes all associated orders on both the originating system and the partner system.
3. Order-Level Manifest Visibility Restored
Orders added after the initial publish now correctly display manifest details in the partner’s order details screen, matching the originating system behavior.
4. Expected Arrival Consistency Maintained
Expected arrival information continues to display correctly for all orders across both systems.
Zipcode Entry Not Updated After Removing Single Zipcode Connection
Overview
An issue was identified where removing a single zipcode–hub connection did not fully update the corresponding zipcode entry. After unassigning the default zipcode Hub Connection, the zipcode record continued to retain outdated region and sub-region values, resulting in incorrect routing data.
Key Fixes
1. Zipcode Entry Correctly Updated on Unassignment
When a single zipcode–hub connection is removed, the associated zipcode entry is now properly updated to reflect the removal.
2. Stale Region and Sub-Region Values Cleared
Outdated region and sub-region values are no longer retained after the connection is unassigned.
3. Consistent Zipcode-to-Region Mapping
Zipcode records now accurately represent their current hub and region associations, ensuring correct coverage and routing behavior.