3.23.28

Patch Changes

• #6857 f5a84f3 Thanks @mirekm! - Attribute dropdowns on products, variants, and models now keep their own option lists.

  Opening one field no longer empties or swaps another field’s values, and the list stays put after blur. Typing filters immediately; the network request stays debounced. Creating a value shows a plus so it reads as an action, not another choice.

• #6845 36f9b43 Thanks @mirekm! - When adding products to a channel with the bulk publish wizard, leaving the price blank now keeps each product’s current prices instead of requiring a new price for every product.

  That means you can update stock or visibility for products already in the channel without overwriting variant prices. The review step shows current prices as placeholders, marks rows that will change, and warns before a single price would flatten different variant prices or leave unpriced variants unlisted. New products still need a price so they can be listed in the channel.

• #6850 2f34302 Thanks @lkostrowski! - Close the app extension popup when the app dispatches a redirect action to a Dashboard page. Previously the Dashboard navigated behind the popup and the popup stayed open on top of the new page.

• #6856 214da34 Thanks @mirekm! - Customers can now be grouped into customer types, each with its own set of attributes.

  Configuration has a new Customers section with Customer types and Customer attributes. A customer type defines the attributes its customers share, so details like tax ID, account manager, or contract tier live on the profile as proper fields instead of metadata or free-text notes. Types can be created, renamed, given a default, and have attributes assigned, reordered, or unassigned — the same way product and model types work.

  On a customer profile you can pick the type, fill in its attributes, and jump to the type's settings from the attributes card. The type also appears as a badge in the profile header, linking to that type's tab on the customer list. The customer list uses type tabs (like models) and the current where API for other filters.

  The customer detail page has been reorganized around this: the header carries status, type, and member-since; the main column shows channel-scoped order KPIs, recent orders, and attributes; contact details, addresses, external reference, and gift cards sit in the sidebar. Recent orders rows are clickable across the full row.

• #6843 21f82cd Thanks @lkostrowski! - The "Filterable in storefront" attribute setting is now marked as deprecated. A DEPRECATED badge next to the setting explains, on hover, that the field will be removed in Saleor 3.24 and that attribute metadata should be used instead.

  Dashboard builds running against the staging schema (FF_USE_STAGING_SCHEMA=true) already drop the setting entirely: the toggle and its "Position in faceted navigation" field, the "Use in faceted search" column in the attribute list, and the "Filterable in Storefront" filter are hidden, and neither filterableInStorefront nor storefrontSearchPosition is sent when creating or updating an attribute.

• #6852 6b22f12 Thanks @lkostrowski! - App extensions listed in the "more actions" menu (e.g. on the product page) now show the app's logo, with a placeholder icon when the app has no logo. Previously most pages rendered extension entries without any icon.

• #6814 8924d06 Thanks @offx366! - Keep every order line in a fulfillment when selecting warehouses, so one tracking number and one customer notification can cover the whole shipment.

• #6853 c4a0350 Thanks @lkostrowski! - Support the App Bridge redirectToApp action. Apps can now redirect to another installed app by its manifest identifier - the Dashboard resolves the identifier to the installed app, builds its URL, appends the optional path and navigates in the same tab, like the redirect action does.

• #6842 3db7306 Thanks @lkostrowski! - SEARCH_ACTION extensions can now declare options.aliases — extra terms the command palette (Cmd+K) matches against, on top of the extension label and the owning app's name.

  Use it when the words a user types are not the words in your label. An action labelled "Configure Avalara" can be found by typing "taxes", "legal" or "avatax":

  {
    "label": "Configure Avalara",
    "mount": "SEARCH_ACTION",
    "target": "POPUP",
    "url": "https://example.com/action",
    "options": {
      "aliases": ["taxes", "legal", "avatax"]
    }
  }

  Aliases are matched, never displayed, and matching is case-insensitive and typo-tolerant like the rest of the palette. The option is valid only on the SEARCH_ACTION mount; setting it elsewhere fails manifest validation.

• #6849 0d85545 Thanks @lkostrowski! - SEARCH_ACTION extensions can now be scoped to the channel details view with options.views: ["CHANNEL_DETAILS"].

  Use it for actions that only make sense while looking at one channel — a payment app's per-channel configuration, for example. The action appears in the command palette (Cmd+K) only on /channels/<id>, and receives that channel's id:

  {
    "label": "Channel payment settings",
    "mount": "SEARCH_ACTION",
    "target": "POPUP",
    "url": "https://example.com/channel-config",
    "options": {
      "views": ["CHANNEL_DETAILS"]
    }
  }

  The extension is opened with channelId as a query param, holding the channel's global id (e.g. Q2hhbm5lbDox). Resolve the slug from it if you need one. As with every other view, omitting options.views still means the action shows everywhere.

Full Changelog: 3.23.27...3.23.28