QA Release — 2026-08-06

Tag qa-2026-08-06 · Created: 2026-08-06 · Last Updated: 2026-08-06

What shipped to QA in this release (changes since 2026-07-20), grouped by area. The Ref column is stable — cite it when reporting. Rows marked → How to test are expanded at the bottom.

✨ Highlights

🖥️ Admin portal 4

🏪 Merchant portal 19

🧩 Across both portals 3

🔑 Sign-in & behind the scenes 3

🧪 How to test 24

Only the items that need more than a glance. Click to expand.

#1091 — signing in returns you to the portal that started it

• Before: a magic link opened on the merchant portal came back to a 404. On the admin portal it could report an invalid state instead of signing you in.
• Now: the return URL is derived from the portal that began the flow.
• Steps:
  1. On the merchant portal sign-in page, request a magic link and follow it. Expect the merchant dashboard, not a 404.
  2. Repeat on the admin portal. Expect the admin dashboard and no invalid-state message.
  3. Sign out of both and repeat once more, to confirm it is not a one-time success from a warm session.
• Note: links issued before this release will not work — request a new one. Google and Microsoft sign-in take the same path but are not covered by these steps; they need their own pass.

— (no PR) — "Open in merchant portal" opens QA

• Before: choosing a reason and continuing opened https://localhost:7710, which does not resolve outside a developer machine, so the new tab failed to load. It behaved this way on QA since 2026-07-13.
• Now: it opens https://portal.qa.qiiub.com.
• Steps:
  1. Sign in to the admin portal as SystemAdmin or PartnerAdmin.
  2. Go to Platform › Merchants and open a merchant.
  3. Click "Open in merchant portal", pick a reason, continue.
  4. Expect a new tab on portal.qa.qiiub.com, already signed in to that merchant. Check the address bar — if it reads localhost, this has regressed.
• Note: this was a build-configuration fix, not a code change, which is why it has no PR number. The cause and the guard that now prevents it are recorded in the deploy notes for this release.

#1033 — the conflict dialog when two people edit the same record

• Before: the second save overwrote the first, and the first person's change disappeared with no message.
• Now: the second save opens a dialog listing each conflicting field with their value and yours, offering apply-merged, discard-mine, and keep-editing.
• Steps:
  1. Open the same record in two browser tabs — a merchant group or server in admin, or a customer, category or adjustment drawer in the portal.
  2. In tab A change one field and save. Expect success.
  3. In tab B change a different field and save. Expect the conflict dialog, not a plain error toast.
  4. Choose apply-merged. Expect both changes to survive — reload and confirm tab A's field and tab B's field are both present.
  5. Repeat and choose keep-editing. Expect the dialog to close with your unsaved edit still in the form. Escape does the same.

#961 and #968 — stock moves on sale, return and void

• Before: completing a sale did not reduce stock at all; it needed a separate adjustment. Voiding a return left its tracking rows live, so voiding the original sale under-restored stock and a second return was blocked.
• Now: each sale, return and void writes its own movement in the same transaction, and a void nets out what was already returned.
• Steps:
  1. Precondition: the portal has no sales screen, so the sale has to come from a POS terminal on QA or from the API through Scalar. The portal side of this test is Inventory › Stock and Inventory › Movements.
  2. Note quantity on hand for a product in Inventory › Stock.
  3. Sell 10 units. Expect quantity down by 10 and a movement row.
  4. Return 3 units. Expect quantity up by 3 and a second movement row.
  5. Void the original sale. Expect +7, not +10 — the 3 already returned must not be credited twice.
  6. Attempt a second return against that sale. Expect it to be allowed rather than blocked.
• Note: selling more than you have on hand is permitted by design (offline-first), so a negative quantity is not a bug here.

#1076, #1060 and #1085 — a Manager gets the sidebar and adjustments back

• Before: the module list the sidebar is built from refused a Manager, so every module-gated item vanished and the sidebar collapsed to Dashboard and Labels. The adjustment screens behind those items also refused the role, and the lookups the create form needs were Admin-only, so its dropdowns came back empty.
• Now: all three layers allow Manager.
• Steps:
  1. Sign in to the merchant portal as a user whose role is Manager, not Admin.
  2. Expect the full sidebar — Purchase orders, Purchase receipts and Adjustments present, not just Dashboard and Labels.
  3. Open Inventory › Adjustments and create one. The product, reason-code and location dropdowns must populate with data.
  4. Complete the adjustment. Expect success, not "not authorized".
  5. If a lookup fails, expect an error state with a retry button — not an empty dropdown that reads like a merchant with nothing configured.
• Note: write endpoints stay Admin-only outside adjustments, and opening a location detail by typed URL still refuses a Manager. Both are intentional, not gaps in this fix.

#1112 — reason codes that require a note

• Before: a reason code declaring that it needs a note was accepted with the note blank.
• Now: it is enforced when the adjustment is created, when its header is saved, and when it is completed.
• Steps:
  1. In Settings › Reason codes, turn on the note requirement for a code, save.
  2. In Inventory › Adjustments create one with that code and no note. Expect a rejection.
  3. Add a note, save, then complete it. Expect success.
  4. Edit the header and blank the note out. Expect a rejection there too.
  5. Enter a note of only spaces. Expect the same rejection — whitespace is treated as blank.
• Note: the requirement is satisfied by the header note, so adding or removing lines cannot push a compliant adjustment into violation.

#1053 — supplier minimum order amount

• Before: an order below a supplier's minimum submitted fine and the supplier rejected it later.
• Now: submit is refused below the minimum.
• Steps:
  1. Open a supplier, set a minimum order amount of 500, save. Leave it empty on a second supplier as a control.
  2. Build a purchase order for the first supplier totalling under 500. Saving it as a draft must still work.
  3. Submit it. Expect a refusal referencing the minimum.
  4. Add lines until the total passes 500 and submit. Expect success.
  5. Submit a small order for the control supplier. Expect no minimum enforced.
• Note: this is a money floor for the whole order. It is a different rule from the per-line quantity minimum on a product-supplier, which already existed.

#972 and #1001 — recreate a purchase order from an earlier one

• Before: rebuilding a recurring order meant re-entering every line.
• Now: "Reorder from a previous PO" creates a new draft copy.
• Steps:
  1. From the purchase order list or a PO's detail, use "Reorder from a previous PO" and pick an order with several lines.
  2. Expect a preview, then a new draft with the same supplier and lines and its own number. The source order must be untouched.
  3. Close the dialog and reopen it on a different source order. Expect a loading skeleton, not a flash of the previous order's lines.
  4. Try to copy an order whose location has since been deleted. Expect a clear error instead of a draft that fails to open.

#1025 — overdue and due-today purchase orders

• Before: you had to open each order to see its expected date had passed.
• Now: the list flags them.
• Steps:
  1. You need a submitted or partially-received order with an expected date in the past. Set one to yesterday if none exists.
  2. Open Purchase orders. Expect that order flagged as overdue in the list.
  3. Set another order's expected date to today. Expect a due-today flag, distinct from overdue.
  4. Confirm a draft with a past date is not flagged — a draft was never ordered — and neither is an order with no expected date at all.

#1087 — who last changed an inventory document

• Before: "Updated by" kept showing whoever created the document, even after someone else completed or cancelled it. The attribution looked valid and was wrong.
• Now: each status change stamps the operator who made it.
• Steps:
  1. As user A, create an adjustment and leave it as a draft.
  2. As user B, open it and complete it.
  3. Reopen the document. Expect "Updated by" to name B, not A.
• Note: documents whose status last changed before this release keep the attribution they were saved with — only new status changes are stamped.

#954 and #1010 — one reorder quantity everywhere

• Before: Low Stock computed restock-level minus on-hand, ignoring what was already on order, the supplier's minimum, and whether any was needed at all. The reorder worksheet used the real engine, so the two showed different numbers for the same item.
• Now: all three surfaces use the engine.
• Steps:
  1. Pick a product that is below its reorder point and has an open purchase order for some of the shortfall.
  2. Note the suggested quantity on Inventory › Low stock, on Inventory › Reorder worksheet, and in the low-stock report.
  3. Expect the same number in all three, and expect it to be net of the quantity already on order.
  4. Confirm a product with a reorder point of zero is not proposed at all.

#948 — location pickers reach every location

• Before: these were plain dropdowns filled from a single 100-row page, so any location past the first 100 could not be selected.
• Now: each is a searchable box that queries the server.
• Steps:
  1. Precondition: a merchant with more than 100 locations.
  2. Open the purchase-order create form and type part of the name of a location you know sorts near the end of the list. Expect it to appear and be selectable.
  3. Repeat on the purchase receipt header, the adjustment form, and a transfer.
  4. In admin, repeat in the Register-device drawer on a merchant's Devices tab.

#949 — the reorder worksheet says when its list was cut short

• Before: a proposal larger than the server's cap came back shortened with nothing saying so, so a partial list read as the complete set of items needing reorder.
• Now: a banner states how many are shown out of how many are below their reorder point.
• Steps:
  1. Precondition: a location with enough products below their reorder point to exceed the cap. If you cannot build one, ask for a seeded merchant — the notice cannot be triggered otherwise.
  2. Open Inventory › Reorder worksheet for that location.
  3. Expect a banner naming both numbers — shown, and the total below reorder point.
  4. Confirm the generate button is still enabled. The notice is informational; it must not block you from ordering what is listed.

#956 — the reorder worksheet is no longer a dead end

• Before: opening it by direct URL while the scope was "all locations" showed "Pick a location" with no switcher on the page, so there was no way to pick one.
• Now: the location switcher renders there.
• Steps:
  1. Set the location scope to "all locations".
  2. Paste the reorder worksheet URL straight into the address bar rather than navigating to it.
  3. Expect the location switcher in the top bar. Pick a location and expect the worksheet to load.

#992 — dashboard figures follow the selected location

• Before: the location filter was dropped on the way to the server, so every figure was a total across all locations.
• Now: it is applied.
• Steps:
  1. Precondition: a merchant with at least two locations that both have sales.
  2. On the Dashboard, select location A and note a figure.
  3. Switch to location B. Expect the figure to change.
  4. Expect A's figure not to equal the all-locations total. Two locations showing the same number is the bug returning.

#1079 — clearing weight or barcode on a variant

• Before: clearing the field and saving reported success and kept the old value — the write never reached the database.
• Now: it saves as empty.
• Steps:
  1. Open a product with variants and pick one that has a weight and a barcode filled in.
  2. Clear the weight, save, then reload the product. Expect the weight empty.
  3. Repeat for the barcode, and for a price bound.
  4. Confirm that editing an unrelated field and saving leaves weight and barcode alone — omitting a field must still mean "leave it as it is".

#983 — documents survive the deletion of a code they used

• Before: deleting a payment method or reason code broke the documents that referenced it — an adjustment came back as a 404 and a sale's payments came back empty.
• Now: the code is stored on the document when it is written, so the document still opens and still shows that code.
• Steps:
  1. Create and complete an adjustment using reason code X.
  2. Delete or deactivate X in Settings › Reason codes.
  3. Reopen the adjustment. Expect it to open normally and still display X — not an error, not a blank reason.
  4. Repeat with a sale paid by a payment method you then delete. Expect its payment lines to still be listed.

#970 — inactive tax groups on new assignments

• Before: an inactive tax group could still be assigned to something new.
• Now: a new or changed assignment is refused; what was already assigned is left alone.
• Steps:
  1. Deactivate a tax group that is not in use anywhere.
  2. Try to assign it to a product, a location, a tax holiday, and a customer tax profile. Expect each to be refused.
  3. Now take a record that referenced a different group before that group was deactivated. Edit an unrelated field and save. Expect success — this must not be blocked.
  4. Deactivate a group that is in use. Expect the deactivation itself to be allowed.

#1040 — the same variant twice on a price change

• Before: the request reached the database, tripped a constraint, and came back as an unexpected error with nothing naming the cause.
• Now: it is refused up front with the duplicated item named.
• Steps:
  1. Start a price change and add a variant.
  2. Add the same variant again and save. Expect a validation message naming it.
  3. Add two different variants and save. Expect success — the rule must not over-reject.

#993 — the "Add product" drawer keeps its list

• Before: after adding a line the product list went blank and stayed blank until you toggled the stock filter.
• Now: it repopulates.
• Steps:
  1. Open a draft purchase order and use "Add product". It opens in browse mode with the search box empty.
  2. Add a product. Expect the list to still be populated afterwards.
  3. Add a second product without touching the filter. Expect that to work too.

#957 — the module catalog is not empty

• Before: the page rendered with no modules and every stat card at 0, even though the server was returning 26 of them.
• Now: it reads the response correctly.
• Steps:
  1. Open Platform › Modules.
  2. Expect a populated list and stat cards with non-zero counts.
  3. Confirm the count matches what the modules endpoint returns if you check it in Scalar.

#943 — module category labels and the core-module lock

• Before: the per-merchant module grid showed raw lowercase category keys, and a core module could be switched off.
• Now: categories show names in both languages, and core modules are locked with the server refusing a forced attempt.
• Steps:
  1. Open Platform › Merchants, open a merchant, go to its Modules grid.
  2. Expect readable category names. Switch the language to Spanish and expect them translated, not keys.
  3. Find a core module. Expect its toggle locked.
  4. Repeat on the partner-side path to the same grid — the refusal is enforced on both.

#1008 and #995 — device status on the partner view

• Before: the devices tab on a partner's merchant detail read every device as "Sin conexión", because it was matching status values the server never sends.
• Now: it maps the real ones — pending, active, disabled, revoked.
• Steps:
  1. Open Partner › Merchants, open a merchant, go to Devices.
  2. Expect statuses that vary by device rather than every row offline.
  3. Compare the same device on Platform › Devices. Expect the same label in both places.
  4. Disable a device and confirm both views follow.

#982 and #1128 — email through the outbox

• Before: a failure while sending simply lost the message.
• Now: every send is queued first, then delivered, so a failure can retry.
• Steps:
  1. Invite a user from Platform › Users. Expect the invitation to arrive and its link to work.
  2. Request a magic link on each portal. Expect both to arrive.
  3. Confirm nothing arrives twice — the queue must not double-send.
• Note: the retry itself cannot be triggered from the portal; these steps confirm normal delivery still works after the provider change. See the appendix.

🔧 Technical — not QA-testable 13

Referenced in development but with nothing to verify through the normal portal flow — listed so a referenced number never dead-ends.