Talk to an Expert

Help Center

Find answers, explore features, and get the most out of Grasshopper with our step-by-step guides and resources.

Help Center Menu

14 January 2026

Submit a Support Ticket

    Grasshopper 3.24.34 Release Notes

    Features

    Webhook Enhancement – Item Shortage Events on Manifest Close

    Overview

    To improve downstream visibility and automation around warehouse discrepancies, a new item shortage webhook has been introduced.
    This webhook emits real-time events when a manifest is closed (force) and items are identified as shortages, allowing partners and internal systems to react immediately at item-level granularity.

    Key Enhancements

    1. New Webhook Topic: item_shortage

    • A new webhook topic is now available: item_shortage.
    • Designed to notify consumers whenever an item is identified as a shortage during manifest force close.

    2. Trigger Condition

    • The webhook is triggered on Manifest Close.
    • During the force close operation, items are evaluated for shortage status.

    3. Item-Level Granularity

    • One event is emitted per item reported as a shortage.
    • If multiple shortages are reported in a single action:
      • Events are emitted sequentially, one per item.
    • This enables precise, item-level handling instead of batch-level ambiguity.

    4. Webhook Payload

    Each item_shortage event includes the following payload:

    {

    “item_id”: “”,

    “serial_number”: “”,

    “order_id”: “”,

    “sku”: “”

    }

    This minimal, consistent schema allows consumers to quickly identify the affected item and related order context.

    Inventory Management – New React-Based SKU & Item Views

    Overview

    As part of the WMS modernization initiative, the Inventory Management experience has been upgraded by replacing legacy Angular SKU views with new React-based pages powered by the enhanced grid component.
    The new experience improves performance, usability, and scalability when working with unallocated inventory, while introducing clearer item-level visibility and stricter account-based access controls.

    This release focuses on SKU visibility, item drill-down, exports, and performance, while laying the groundwork for future inventory workflows.

    Key Enhancements

    1. New React-Based Inventory Pages

    • Replaced the legacy Angular Summary View with modern React pages for unallocated inventory.
    • New pages leverage the enhanced grid component for improved responsiveness and interaction.

    2. SKU View Screen

    • Introduced a new SKU View with:
      • Advanced filtering
      • Search
      • Sorting across grid columns
    • Optimized for high-volume inventory environments.

    3. Item Breakdown View

    • Added a dedicated Item Breakdown view to:
      • Enable deeper item-level lookup
    • Support drill-down from SKU to individual inventory items
      • Improves traceability and operational clarity.

    4. Drawer Component for Quick Item Access

    • Implemented a drawer component that allows users to quickly inspect item details without leaving the grid context.
    • Reduces navigation friction during inventory review.

    5. Updated CSV Export Reports

    • Updated inventory exports to align with the new views:
      • SKU-level CSV export
      • Item-level CSV export
    • Exports reflect the currently visible and filtered dataset.

    6. Performance Improvements

    • Improved loading performance for the SKU-level query, significantly reducing load times for large datasets.
    • Enhancements ensure smoother navigation and faster analysis.

    7. Improved Inventory Deletion Messaging

    • Updated the Delete Inventory dialog copy to improve clarity and reduce user error during inventory removal actions.

    Account-Based Visibility Rules

    Shippers

    • Shippers can only view:

      • Inventory items they own, or
      • Inventory items they created

    • Certain columns and filters are hidden for shipper users, as defined in the relevant Jira specifications.

    Virtual Carriers

    Virtual Carriers can view only the following inventory data:

    1. Inventory items with their own source_id
    2. Inventory items created and published by the Virtual Carrier
      • Note: Partners cannot create inventory items and publish them to Virtual Carriers.
    3. Order line items published by the Virtual Carrier that were assigned to inventory:
      • Assigned either by the partner or the Virtual Carrier

    This ensures data isolation while maintaining operational visibility.

    Out of Scope (Next Phase)

    The following items are not included in this release and will be handled separately:

    • Updates to the Non-task-based cycle count API to support inventory item scanning
    • Migration of additional Angular pages, including:
      • Item Creation
      • Item Edit
      • Import Items
      • Additional inventory workflows

    New Linked Orders View – React-Based UI for Order Relationships

    Overview

    The existing UI for linked orders—particularly Tag-Along orders—relied on legacy popups that often caused confusion and led to multiple bugs due to unclear hierarchy and relationship context.
    This release introduces a new React-based Linked Orders View, replacing the old popups with structured, intuitive components that clearly visualize how orders are connected and where the current order fits within each relationship.

    The new UI supports all linkage types and provides consistent navigation, visibility, and (where applicable) controlled management actions.

    Key Enhancements

    1. Two New React-Based Popup Windows

    Two modern React popups replace the legacy experience:

    1. Linked Orders Overview
      • Displays all order relationships in a clear, structured layout.
      • Allows unlinking where actions are permitted.
    2. Add Link Popup
      • Enables adding a new parent or follower order.
      • Supports all linkage types consistently.

    Both popups are shared across all order-linking scenarios.

    2. Support for All Linkage Types

    The new Linked Orders View supports the following relationship types, each with a dedicated tab, layout, and rules:

    Tag-Along Orders

    • Structure: Two-level hierarchy
      • Parent (Master)
      • Follower(s)
      • Includes sibling visibility
    • Actions:
      • Add link
      • Remove link (one connection at a time)
    • Permissions:
      • Follower can remove only its own connection to the parent
      • Parent can remove followers one at a time
      • When the last follower is removed, the parent becomes a standalone order

    • Labels: Parent, Follower
    • Navigation: Orders are clickable links
    • Info Text:


      “Tag-Along orders are delivered together with a main ‘parent’ order, typically sharing the same address and customer.”

    Source / Derived Orders (Clones)

    • Use Case: Orders created via cloning only
    • Structure: Horizontal layout
    • Depth: Up to 3 generations
    • Actions: None
    • Labels: Parent, Child
    • Navigation: Orders are clickable links
    • Info Text:

      “Parent–child orders represent cases where a new order (child) was generated to complete or re-deliver an uncompleted original order (parent).”

    Related Orders

    • Use Case: Flexible, user-defined relationships
    • Structure: Tree layout similar to Tag-Along
    • Actions:
      • Add link
      • Remove link
    • Validation: None
    • Labels: None
    • Navigation: Orders are clickable links
    • Info Text:

      “Related orders represent flexible links between orders that share a business connection or any other relationship manually defined by the user.”

    Split Orders

    • Use Case: Orders created from a split operation
    • Structure: Horizontal layout
    • Actions: None
    • Labels: Sibling
    • Navigation: Orders are clickable links
    • Info Text:


      “Orders created from the same original order that was split into two or more parts.”

    Claims

    • Structure: Tree layout similar to Tag-Along
    • Hierarchy: Claims are children of the originating order
    • Actions: None
    • Labels: Order, Claim
    • Navigation: Orders are clickable links
    • Info Text:


      “Displays claims or issue reports associated with this order.”

    Billing Links

    • Use Case: Orders linked to billing or invoicing records
    • Structure: Tree layout similar to Tag-Along
    • Actions: None
    • Labels: Order, Bill
    • Navigation: Orders are clickable links
    • Info Text:


      “Shows billing or invoicing records related to this order.”

    3. New API for Link Discovery

    • Added a new API to retrieve orders with the same address and shipper from Postgres.
    • Used to support intelligent linking suggestions.
    • Implementation coordinated with Dina.


    Scope

    Included:

    • Full replacement of legacy linked-order popups
    • React-based UI for all order relationship types
    • Controlled linking/unlinking actions
    • Unified UX across Tag-Along, Split, Related, Billing, Claims, and Clone flows
    • New Postgres-based API for related-order discovery


    Not Included:

    • Changes to underlying business rules for order relationships
    • Bulk unlink operations
    • Cross-account linking

    Order Details Bookmark – History Items Revamp

    Overview

    The existing History Items feature lacked clarity around its purpose, which limited user adoption and caused confusion about how and when it should be used.

    This enhancement introduces clearer naming, improved UI cues, and controlled persistence behavior—repositioning the feature as a simple and intentional way for users to bookmark orders for quick access.

    The update applies minimal functional changes while significantly improving usability and discoverability.

    Key Enhancements

    1. UI Text & Label Improvements

    To better reflect the feature’s intent:

    • Order Details Screen (Angular):
      • Renamed the “Minimize” button to “Bookmark”.
    • Bookmark Dialog (React):
      • Updated the dialog title from “History Items” to “Bookmarked Orders”.

    These changes make it clear that the feature is designed for intentional bookmarking rather than passive history tracking.

    2. Bookmark Persistence Rules

    • Bookmarked orders are stored in localStorage and persist:
      • Per browser
      • Per device
      • Per user session


    Bookmarks do not persist:

    • Across different user accounts
    • When switching between licensees for shippers with multiple accounts

    This ensures bookmarks remain relevant to the active user and account context.

    3. Bookmark Limit Enforcement

    • Users can bookmark up to 20 orders per browser.
    • If a user attempts to bookmark a 21st order:
      • The action is blocked.
      • A snackbar message is displayed:
    • “You’ve reached the bookmark limit. Remove a saved order to add a new one.”

    This prevents uncontrolled growth while maintaining usability.

    4. Icon Updates

    To visually reinforce the bookmarking behavior:

    • Replaced the existing icon with a Bookmark icon in:
      • React Top Bar (previously a clock-with-arrow icon)
      • Order Details Page (Angular) next to the new “Bookmark” button (previously a downward arrow)

    Icon usage will rely on either a newly provided asset or an existing icon from the approved icon library.

    Orders Grid – Serial Number Filter

    Overview

    Accounts that rely heavily on serial-number tracking were unable to search or filter orders by an item’s serial number in the Orders grid. This limitation forced users to rely on manual workarounds, slowing investigations and exception handling—especially when resolving duplicate or conflicting serial numbers.

    This enhancement introduces a Serial Number filter to the Orders grid, enabling users to quickly surface orders that contain specific serial-numbered items.

    Key Enhancements

    1. New Serial Number Filter

    • Added Serial Number as a new filter in the Orders grid.

    • Filter type: Multi-select Chip Input, matching the behavior and styling of the existing Order ID filter.

    • Placement:
      • Hidden under More+ by default.
      • Visible for users belonging to shipper accounts.

    2. Exact-Match Filtering Logic

    • Orders are returned if they contain at least one item whose serial number exactly matches one of the values provided.
    • Matching rules:
      • Strict match only (no partial or prefix matching).
      • Multiple serial numbers apply OR logic:
        • Orders containing Serial A or Serial B will be shown.

    3. Works Across Order States

    • The filter applies to both:
      • Active orders
      • Closed orders

    • Aligns Orders grid behavior with existing Inventory serial number search capabilities.

    Defect Fixes

    Downloaded Manifests and BOL Displayed EST Instead of Configured Timezone

    Overview

    Clients reported that downloaded shipment documents—including Manifest, Bill of Lading (BOL), and Master BOL—were displaying time values in EST, even when the account or route was configured to use a different timezone (e.g., PST or CST).
    This discrepancy affected delivery windows and other time-related fields on exported documents, leading to confusion and inconsistencies between the GH UI and generated paperwork.

    Key Fixes

    1. Correct Timezone Resolution for Document Generation

    • Manifest, BOL, and Master BOL generation now correctly apply the configured timezone for the route or destination region.
    • Removed hardcoded or default EST fallbacks in document rendering logic.

    2. Consistent Time Display Across Documents

    • All time-based fields (including delivery windows and shipment timestamps) are now rendered using the same timezone logic as the GH UI.
    • Ensures consistency between on-screen data and downloaded documents.

    3. Applies to All Shipment Documents

    • Fix covers:
      • Manifest
      • BOL
      • Master BOL
      • DSS Final Mile reports included in this workflow

    Unable to Download CSV File from Outbound Report for Extended Date Ranges

    Overview

    Client reported an issue where the Outbound Report CSV export failed to download when using an extended date range.
    While smaller ranges (e.g., October only) downloaded successfully, attempting to export data for October 1, 2025 through December 31, 2025 caused the export process to remain in a perpetual loading state, with no file generated or saved.

    The issue was reproducible for data across multiple hubs, and impacted customers’ ability to extract operational and analytical data.

    Key Fixes

    1. Resolved Export Blocking for Large Date Ranges

    • Fixed a backend issue that prevented CSV generation when exporting larger datasets from the Outbound Report.
    • Ensured the export process completes successfully even when spanning multiple months.

    2. Improved Export Stability

    • Optimized the export execution path to prevent timeouts or stalled responses during file generation.
    • The download flow now correctly transitions from loading to file delivery.

    3. Consistent Behavior Across Hubs

    • Verified correct export behavior for multi-hub data