content: consumables count down when a custody hold ends (shelf.nu#2800)

[carlosvirreira]

Triggered by

• shelf.nu PR #2800: fix(assets): consume ONE_WAY stock on custody release — View PR

Product change summary

consumptionType was honored on exactly one path: booking check-in. The direct custody path never read it, so releasing a hold on a ONE_WAY consumable handed every unit back to the available pool, Asset.quantity never moved, and the workspace's stock figure drifted further from reality with every use. The UI matched, offering only a "Release" button.

#2800 derives the outcome inside releaseQuantity from the locked asset row. On a consumable the units are consumed, the total is decremented, and an explicit split lets an operator hand back whatever was not used. The custody row's action reads Mark as consumed. TWO_WAY and legacy assets are byte-for-byte unchanged, and the server rejects a consume on them.

Deployed: the Deploy workflow for merge commit 36fcdf08 completed successfully at 06:32Z today.

Content changes

Factual corrections

• content/knowledge-base/quantity-tracked-assets-and-consumables.mdx — the Quantity-aware custody section stated the pre-fix behavior as a rule: "Releasing custody, fully or partially, returns those units to the available pool." Replaced with two sub-sections, one per consumption type, covering the Mark as consumed action, the two-field dialog, the permanence of the used-up count, the activity entry, and the low-stock interaction.
• content/knowledge-base/quantity-tracked-assets-and-consumables.mdx — the mobile section said "Tap a holder's custody row to release units back to the pool." Now inaccurate for consumables. See the Companion note under Review notes.
• content/knowledge-base/quantity-tracked-assets-and-consumables.mdx — "Used up (one-way)" described the drop as happening "when the booking is checked in". That was the whole defect. Now stated as applying on both routes stock leaves by.
• content/features/consumables-tracking.mdx — "release any portion back" was a blanket claim across both consumption types.
• content/features/custody.mdx — same blanket "assign or release any quantity" claim in the Quantity-Aware Custody section.

Content enhancements

• content/glossary/quantity-tracked-assets.mdx — this page already claimed "Consumables reduce permanently when handed out." It was aspirational until this fix and is now true, so it is tightened with the specifics rather than corrected.
• content/knowledge-base/quantity-tracked-assets-and-consumables.mdx — "Every quantity change is logged" now includes the custody consume, and notes that consumed and returned units are logged separately.
• content/features/consumables-tracking.mdx — same addition to "Every stock change is on the record".
• content/knowledge-base/quantity-tracked-assets-and-consumables.mdx — new Editing stock in bulk section. Carried-over follow-up, held back since 2026-08-03 while PR content: pooled stock: booking availability per dates, and low-stock alerting (shelf.nu#2770, #2775, #2780) #215 owned this file. Written against today's behavior: Import-ready carries all four quantity columns, so the manual pass the follow-up described now applies to Standard exports only.

New content

• content/updates/consumables-consume-on-custody-release.mdx — changelog entry.

Review notes

• The one-time-check note. Both the KB and the changelog entry tell readers that a consumable's count may currently read high, because units released from custody used to come back. That is a real data condition in every existing workspace, and staying silent would leave people trusting a number that is wrong. It is written as a single corrective action, not as an alarm.
• The Companion claim is deliberate and source-checked. The live app is 1.2.0 (iOS released 2026-07-23, Play listing 1.2.0), which predates this merge and still labels the action "release" and sends no consumed field. The service computes consumed ?? (canConsume ? quantity : 0), so a release from today's installed app fully consumes a consumable. The KB says the outcome follows the asset rather than the device, and that the app's wording and its partial field catch up in a future release. Both halves are true today.
• No alternatives sweep. This is a correctness fix to consumption behavior the comparison pages already describe at a high level, not a new capability. Claiming a differentiator here would be manufactured.
• Pricing files untouched. Nothing about plan gating changed.

Screenshots still needed (manual capture required)

• content/knowledge-base/quantity-tracked-assets-and-consumables.mdx — the Mark as consumed dialog. The pipeline was run: the demo workspace has two quantity-tracked assets, both returnable and neither in custody, so there is no consumable custody row to shoot. Capturing it means creating a ONE_WAY asset and assigning custody in the shared demo workspace, which I did not do unattended. The dialog can be opened without submitting, so this is a quick manual capture once such an asset exists.

Impact scope

• End users affected: anyone handing out consumables as custody. Their stock figures behave differently from today, and their historical figures may need one correction.
• Prospects affected: consumables and PPE evaluators, where "does the count actually go down" is the whole question.
• Pages modified: 4
• Pages created: 1

---

Generated by Shelf Content Intelligence — PR→Website Sync

[coderabbitai]

Warning

Review limit reached

@carlosvirreira, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 56 minutes

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 66687ee0-0484-40a0-acbd-99a5a7e40619

📥 Commits

Reviewing files that changed from the base of the PR and between 06a0588 and 497a2bd.

📒 Files selected for processing (5)

• content/features/consumables-tracking.mdx
• content/features/custody.mdx
• content/glossary/quantity-tracked-assets.mdx
• content/knowledge-base/quantity-tracked-assets-and-consumables.mdx
• content/updates/consumables-consume-on-custody-release.mdx

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

Preview deployment

https://3f3a6082.shelf-nu.pages.dev