v075

BazBags

v075 (2026-05-05)

Full Changelog Previous Releases

• v075: remove divider above Split stack in shift+right-click menu

v074

BazBags

v074 (2026-05-05)

Full Changelog Previous Releases

• v074: cleaner context menu, split stack entry, suppressed Blizzard auto-trigger
• v073: bag-item shift+right-click menu uses BazCore's shared registry
• Link License → GPL v2 page, Version → GitHub releases
• Link the WoW Midnight badge to the official Blizzard page
• Wrap 'Part of BazAddons' badge in link to bazaddons.com
• Add 'Part of BazAddons' badge + fix Version badge URL
  Link the addon to the suite via a shields.io badge (image-only so it
  renders cleanly on CurseForge too). Also corrects the Version badge
  URL from bazsec/ to BazAddons/ after the org reorg.

v073

BazBags

v073 (2026-05-05)

Full Changelog Previous Releases

• v073: bag-item shift+right-click menu uses BazCore's shared registry

v072

BazBags

v072 (2026-05-03)

Full Changelog Previous Releases

• v072: user guide refresh
  Reorganise the in-game User Manual page, drop dev-y internal-mechanics
  text in favour of user-focused prose, add coverage for recently shipped
  features, match the new player-readable style across the suite.
• docs: refresh user guide
  • Reorganise pages for clearer top-down flow
  • Add coverage for recently-shipped features
  • Drop dev-y internal-mechanics text in favour of user-focused prose
  • Match the new player-readable style across the suite

071

BazBags

071 (2026-05-02)

Full Changelog Previous Releases

• BazBags v071 - Expansion category tag + tooltip option. Two related additions surfacing the expansionID metadata that C_Item.GetItemInfo already returns. (1) New Expansion rule type for category matching. Categories.TYPE_OPTIONS gets a new entry, Categories.OPS_FOR_TYPE supports is / is at least / is at most operators (so users can build categories like 'Dragonflight Gear', 'Current Expansion Only', or 'Pre-Cataclysm Quest Items'), and the EXPAC_OPTIONS list is built lazily at module load by iterating _G['EXPANSION_NAME'..i] from 0 upwards until the first gap. That way future expansions automatically show up in the rule editor with their localized names without needing an addon update - whatever Blizzard names EXPANSION_NAME11 we get for free. ItemMeta was already capturing expacID into the meta table; just wire it into MatchTag, FormatTag, and MakeDefaultTag, plus the per-type label helpers in CategoriesPage.lua so the value dropdown shows expansion names. (2) New Tooltip.lua module appends an Expansion line to item tooltips when the new Show Expansion toggle is on (Settings > BazBars > General Settings > Tooltip). Off by default. Hooks TooltipDataProcessor.AddTooltipPostCall(Enum.TooltipDataType.Item, ...) so it shows up everywhere item tooltips render - bags, character pane, merchant, AH, chat-link hover. The hook is a no-op when the setting is off so the install cost is zero until the user enables it. Both features pull from the same expansionID source, so toggling the tooltip line and setting up Expansion-rule categories paint a consistent picture, bump to 071

070

BazBags

070 (2026-05-02)

Full Changelog Previous Releases

• CategoriesPage: two layout fixes for the Match Rules section. (1) Swap the Match Mode dropdown and the Add Match Rule button so Match Mode sits in the LEFT card and Add sits in the RIGHT card. The previous layout put the dropdown's "Match Mode" label on the right side of the row, which read awkwardly - section labels are conventionally left-aligned and that's where the eye lands first. The Layout engine alternates strictly left/right by emit order, so the swap is just a swap of the two blocks{} appends. For default categories the Reset Rules to Default half-width button stacks under Match Mode in the left card now (used to stack under Add). (2) Hide the entire Pinned Items section + tip on protected (catch-all) categories. Pinning items to Other is functionally meaningless - Other already catches everything that doesn't match another category's rules, so a manual pin to Other is just a redundant override that says "this thing that already lands here should land here." Wrapping the section in if not isProtected removes the noise from the Other detail page entirely, leaving Other with: an info note, the Identity (rename) section, and the Match Priority slider. Cleaner page that reflects the catch-all's locked-down nature, bump to 070

069

BazBags

069 (2026-05-02)

Full Changelog Previous Releases

• Categories: lock Other as a protected catch-all + decouple Match Priority from display order. Two related changes that fall out of the same conversation about handling rule conflicts cleanly. Other was the load-bearing fallback for any item that didn't match another category's rules; if a user deleted it, hid it, or accidentally added rules to it, items the classifier couldn't place would silently disappear from the bag panel. Marking it isProtected makes Delete / SetHidden / AddTag / UpdateTag / RemoveTag / SetMatchMode / ResetTagsToDefault refuse on it, EnsureDefaults re-creates it on every login if it's somehow missing, and the detail page hides the Match Rules section + the Delete section + the Hide-from-bag toggle (rename and reorder still work since those are cosmetic). The category list shows a grey "(catch-all)" suffix on protected entries so the protection is discoverable. Match Priority is the second piece: every category now carries a matchPriority field independent of its display order. Lower numbers match first. Defaults ship with priorities matching their factory display order (Equipment 10, Consumables 20, ... Other 999) EXCEPT Junk which sits at display order 50 but gets matchPriority 5 - that preserves the old "grey items always go to Junk" behaviour without needing the special-case quality=0 shortcut Classify used to have. Custom categories get matchPriority = display order at creation, which keeps "what you see at the top matches first" behaviour for users who don't touch Priority. Users who want a category to live at the bottom of the bag visually but still claim items before broader rules above it can drop its Priority via a numeric range slider in the new Match Priority section on every category's detail page. Classify now walks Categories.GetByMatchPriority() (priority asc with stable tie-break on order then key) instead of Categories.GetAll(). Existing installs get matchPriority backfilled from their order field on first load post-update so behaviour stays identical until the user explicitly changes it, bump to 069

068

BazBags

068 (2026-05-02)

Full Changelog Previous Releases

• Categories: rename "Item Class" -> "Item Type" and "Item Subclass" -> "Item Subtype" in user-facing labels. The WoW API uses ItemClass / ItemSubClass as technical terms but those translate poorly in a user-facing settings UI - "Item Type" reads as plain English ("this is a Weapon", "this is Armor") and Subtype follows naturally for the next level down. Internal tag.type identifiers stay as "class" / "subclass" so the saved-variables format is unchanged - this is a labels-only rename touching the TYPE_OPTIONS array (the Type dropdown's visible options) and the FormatTag display string. No migration needed for existing saves; the storage keys never changed, bump to 068

067

BazBags

067 (2026-05-02)

Full Changelog Previous Releases

• Categories: inline rule editor in place of the two-step Add Match Rule popup. Each existing match rule now renders as one full-width row with everything editable in place: a Type dropdown on the left, an Op dropdown (or static "is" label for single-op types like class/subclass/equipSlot) in the middle, the Value control (input box for name/ilvl, dropdown for class/subclass/equipSlot/quality) filling the rest of the row, and a Remove button right-aligned. Picking any value rebuilds the tag and writes back through Categories.UpdateTag, then refreshes the page so the row re-renders with the new shape - changing Type from "Item Class" to "Item Level" swaps the class-name dropdown for a numeric input automatically. Add Match Rule no longer opens a popup; it appends a default-shaped Name-contains tag and refreshes, so the new row appears in the list ready to edit. Implementation lives in a custom ruleRow widget factory registered against BazCore via O.widgetFactories.ruleRow + O.RegisterFullWidthBlockType("ruleRow"), so the LayoutEngine treats it as a block-level item that gets its own full-width row in the panel. The previous OpenAddTagPopup / OpenAddTagPopup_PickValue / ToValuesMap / SubclassMap / ParseSubclassKey / OPS_MAP helpers are all dead code now and got deleted (~150 lines). New Categories APIs: UpdateTag(key, index, tag) for inline edits, MakeDefaultTag(tagType) for the type-switch reset and the Add button's default tag. Subclass values still store as {classID, subclassID} pairs internally; the UI encodes them as composite "class:subclass" strings only when needed for the menu radio's value field, decodes back on save, bump to 067

066

BazBags

066 (2026-05-02)

Full Changelog Previous Releases

• CategoriesPage / Match Rules: pair the Add Match Rule action and the Match Mode dropdown side-by-side at the top of the section instead of stacking them. Add Match Rule sits in the left card, Match Mode in the right card. The Layout engine alternates strictly between left and right columns by widget order, so the new emit order is Add (col 1, half-width) -> Match Mode (col 2, the select widget) -> on default categories Reset Rules to Default (col 1 again, stacks under Add in the same left card). Net result: the action-cluster and the configuration setting share one row of vertical space rather than two, and the dropdown reads as the secondary configuration it is rather than as a primary block above the actions. The "Current Rules" h4 sub-header still sits below the action row as the divider between the actions and the Remove-rule list, bump to 066