content: custody no longer hides a checkout, and custody visibility is enforced end to end

[carlosvirreira]

Triggered by

• shelf.nu PR #2830: fix(custody): custody writes must not overwrite CHECKED_OUT — View PR
• shelf.nu PR #2840: fix(custody): gate custody visibility server-side across payloads, filters and select-all — View PR

Product change summary

#2830. Custody and bookings are independent commitments sharing one Asset.status column, so the last writer won. Assigning custody to an asset with units out on an ongoing booking overwrote CHECKED_OUT, and Available then overstated free stock by exactly the booked quantity; releasing the last custody row advertised a physically absent asset as AVAILABLE. Every custody-driven status write now honours CHECKED_OUT > IN_CUSTODY > AVAILABLE, and giving custody of a checked-out individual asset is refused outright. The bookings list also stopped flagging "Includes unavailable assets" merely because some units of a quantity-tracked pool sit with a custodian.

#2840. The custody-visibility rule for Self-service and Base users was enforced only in the badge component, so the server still shipped custodian names in the list payload and still honoured ?teamMember= filters, including through select-all and the bulk endpoints. It is now enforced server-side in all three places.

Content changes

Factual corrections

• content/knowledge-base/custody-feature-for-long-term-equipment-lend-outs.mdx — "Upon release, the asset becomes fully available again" was unconditional and is now false when the asset is also checked out on a booking. Reworded, with the condition spelled out in a new section.

Content enhancements

• content/knowledge-base/custody-feature-for-long-term-equipment-lend-outs.mdx — new Custody and Bookings Are Separate Commitments section (the refusal on assign, the release behaviour, what a kit does with a checked-out member, the precedence rule) and a new Quantity-Tracked Pools Can Be Both at Once section covering the counting and the bookings-list flag. Two related-article links added. updated added.
• content/knowledge-base/configure-what-self-service-and-base-users-can-see.mdx — one bullet in What the Toggles Never Reach stating that with custody visibility off the name is withheld from the payload and the custodian filter is refused, including under Select all and the bulk actions and QR downloads that run on a selection. Written as how the rule works today; no unfixed exposure is described.

New content

• content/updates/custody-never-hides-a-checkout.mdx — changelog entry for #2830. This is a numbers-are-now-correct fix that customers can see in their own data, so it is above the changelog bar.

Verified against the code, not the PR descriptions

• Precedence and the guard shape: apps/webapp/app/modules/asset/custody-status.server.ts on main (setCustodyDrivenAssetStatus, releaseAssetsToAvailableUnlessCheckedOut), which is what every custody path now routes through.
• The refusal is not universal, and the article says so precisely: assets.$assetId.overview.assign-custody.tsx throws a 400 naming the asset ("... is currently checked out on a booking, so it cannot be given to a custodian. Check the booking in first."), while the kit path (kits.$kitId.assets.assign-custody.tsx) filters the write instead, leaving the checked-out member on CHECKED_OUT without an error. The article describes the kit case as "a kit takes what it can" rather than as a refusal.
• Bookings-list flag: list-bookings-content.tsx now reads !availableToBook || (!isQuantityTracked(asset) && hasCustody(...)). The article and the entry only claim the quantity-tracked half changed; availableToBook still flags both types.

Deliberately not done

• content/knowledge-base/quantity-tracked-assets-and-consumables.mdx was not touched, even though a cross-link from its Quantity-aware custody section would fit. Our own PR content: Companion 1.3.0 is live — correct the mobile gap list, document what shipped #238 is open on that file and edits its frontmatter updated: line, so a second edit is a guaranteed conflict. The substance lives in the custody article, which the QT article already links to in the other direction. Worth folding the cross-link in once content: Companion 1.3.0 is live — correct the mobile gap list, document what shipped #238 lands.
• No changelog entry for #2840. It is a permissions hardening whose user-visible effect is that a restricted role stops being able to do something. Announcing it on /updates would mostly serve to describe what used to be possible, which is not something to publish. The rule as it works today is documented in the KB bullet instead.
• No alternatives, solutions or industries page was touched. #2830 corrects a number that should always have been right; claiming it as a competitive advantage would be presenting a bug fix as a feature.
• No screenshots were captured. Both changes are visible only as a different number or a refusal in a workspace that has an asset simultaneously in custody and checked out, which the demo workspace does not have. Manufacturing it means checking a real booking out there.

Review notes

• The wording "Only the booking flow can take an asset out of Checked out" is the user-facing statement of the precedence comment in custody-status.server.ts. If that ever changes, this article and the update entry both need revisiting.
• node scripts/check-product-claims.mjs passes (543 files, no stale claims).

Impact scope

• End users affected: anyone using custody alongside bookings, and every Self-service or Base user in a workspace with custody visibility off
• Prospects affected: none claimed
• Pages modified: 2
• Pages created: 1
• Pages flagged for review: 1 (the QT article, blocked on content: Companion 1.3.0 is live — correct the mobile gap list, document what shipped #238)

---

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: 112 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: 76a1aa3f-2a5b-42b9-9ad7-86d30d38b67d

📥 Commits

Reviewing files that changed from the base of the PR and between 1a67b40 and 7a601e8.

📒 Files selected for processing (3)

• content/knowledge-base/configure-what-self-service-and-base-users-can-see.mdx
• content/knowledge-base/custody-feature-for-long-term-equipment-lend-outs.mdx
• content/updates/custody-never-hides-a-checkout.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://c851b268.shelf-nu.pages.dev