content: what Self-service and Base users can see (shelf.nu#2824, #2792) - #232
Conversation
Triggered by: - Shelf-nu/shelf.nu#2824 - Shelf-nu/shelf.nu#2792 #2824 restored custom fields on the asset overview for BASE and SELF_SERVICE (hidden since 2026-05-07) and made out-of-category stored values render read-only instead of nowhere. The inline-editing KB stated the pre-fix behaviour as a rule. #2792 made the workspace booking-visibility setting govern the "Add to booking" picker, which had been locked to a user's own bookings regardless of the setting.
Preview deployment |
|
Warning Review limit reached
Next review available in: 54 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 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 configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
WalkthroughThe documentation updates describe booking visibility across five surfaces and read-only custom-field visibility for restricted roles. They also document category-change behavior, permissions, draft booking restrictions, and the related product update. ChangesVisibility documentation
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@content/knowledge-base/adding-assets-and-kits-to-a-booking.mdx`:
- Around line 64-65: Update the booking-visibility guidance near the “Add to
booking” picker description to state that Draft bookings remain visible only to
their creators, even when the workspace setting is enabled. Preserve the
existing rule for non-Draft bookings and the references to the picker, Bookings
index, and command palette.
In `@content/updates/custom-fields-visible-to-view-only-roles.mdx`:
- Around line 1-18: Run npm run lint and resolve all reported failures,
including React effect setState violations and the Next.js redirect warning.
Update the affected implementation without changing the documented behavior of
the custom-field visibility or booking-visibility changes, and verify the lint
command exits successfully.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: d3a49d43-f2b5-4d8a-bf76-7c58790c5958
📒 Files selected for processing (6)
content/knowledge-base/adding-assets-and-kits-to-a-booking.mdxcontent/knowledge-base/configure-what-self-service-and-base-users-can-see.mdxcontent/knowledge-base/editing-asset-fields-inline.mdxcontent/knowledge-base/linking-custom-fields-to-categories.mdxcontent/knowledge-base/user-roles-and-their-permissions.mdxcontent/updates/custom-fields-visible-to-view-only-roles.mdx
| --- | ||
| title: "Self-service and Base Users Can See Custom Fields Again" | ||
| description: "Custom field values now appear on the asset page for Self-service and Base users, read-only. A value left behind by a category change is visible again too, and the booking-visibility setting now reaches the Add to booking picker." | ||
| date: "2026-08-10" | ||
| image: "/images/updates/enhanced-user-permissions.jpg" | ||
| readMoreUrl: "/knowledge-base/user-roles-and-their-permissions" | ||
| layout: "update" | ||
| --- | ||
|
|
||
| Custom fields are back on the asset page for **Self-service** and **Base** users. Since early May, those two roles saw no custom fields at all on an asset's overview, even on assets where every field was filled in. Serial numbers, warranty dates, condition ratings, cost centres: all recorded, none of it visible to the people most likely to be standing in front of the equipment. Owners and Administrators saw the full list throughout, which is why the gap went unreported for so long. | ||
|
|
||
| Now every custom field that holds a value is shown to these roles, read-only. Fields still sitting at **Not set** stay hidden from them, since there is nothing to read and nothing they are allowed to fill in. Nothing changes for Owners and Administrators: every field that had a pencil icon still has one. | ||
|
|
||
| A second gap closed with it, and this one affected every role including owners. A custom field can be linked to specific categories. If an asset moved to a different category, or out of a category entirely, any value written under the old one stopped appearing anywhere on the page. The data was never deleted, but you had to export the workspace to see it. Those values are now shown in the custom fields list, marked read-only. Put the asset back in the matching category and the field becomes editable again. | ||
|
|
||
| Booking visibility got the same treatment. The workspace setting that lets Self-service and Base users see everyone's bookings now also governs the **Add to booking** picker on an asset or kit page, which had stayed locked to a user's own bookings no matter how the setting was configured. The **Bookings** index, the calendar, the command palette, a workspace export, and that picker now all answer the same question the same way. Draft bookings are unaffected: a booking still in **Draft** remains visible only to the person who created it. | ||
|
|
||
| Nothing to configure. The changes apply to your existing assets and bookings the next time you open them. |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
npm run lintRepository: Shelf-nu/website-v2
Length of output: 8275
Run npm run lint and fix the current lint failures before merge.
The repository lint command exits non-zero with React effect setState errors and a Next.js redirect warning.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@content/updates/custom-fields-visible-to-view-only-roles.mdx` around lines 1
- 18, Run npm run lint and resolve all reported failures, including React effect
setState violations and the Next.js redirect warning. Update the affected
implementation without changing the documented behavior of the custom-field
visibility or booking-visibility changes, and verify the lint command exits
successfully.
Source: Coding guidelines
|
Both CodeRabbit findings triaged. Draft-booking exception on the picker rule — valid, fixed in Swept the rest of the PR for the same overclaim rather than fixing only the flagged line:
Locally green before both pushes: |
1 participant
Triggered by
Product change summary
#2824 — Since 2026-05-07, Self-service and Base users saw no custom fields at all on an asset's overview page, even where every field was filled in. A perf optimization skipped the custom-field-definitions query for users who can't update the asset, and the page built its entire list from that array. Customer-reported. The list is now seeded from the asset's own stored values, so view-only roles see every field that holds a value, read-only. "Not set" placeholder rows stay hidden from them. Nothing changes for Owners and Admins.
The same PR fixed a second gap that affected every role including owners: a value written while an asset belonged to a category-scoped custom field stopped rendering anywhere once the asset moved category. Those values are now shown read-only (the action rejects writes to out-of-scope definitions with a 400, so offering an editor would dead-end).
#2792 — The workspace booking-visibility toggle (
selfServiceCanSeeBookings/baseUserCanSeeBookings) now governs the Add to booking picker on an asset or kit page. Previously that dialog gated on role alone, so a workspace could switch the setting on and its Self-service users would still see only their own bookings there while seeing everyone's on/bookings, in the command palette and in exports. Draft visibility is unchanged and independent: a Draft booking is only ever visible to its creator.Content changes
Factual corrections
content/knowledge-base/editing-asset-fields-inline.mdx— stated the pre-fix behaviour as a rule in two places. "Fields that only exist in the old category are no longer shown" is now wrong (they render read-only), and the Permissions bullet said view-only roles "see only fields with values; they cannot enter edit mode" when in practice they saw nothing. Both rewritten to the shipped behaviour.Content enhancements
content/knowledge-base/linking-custom-fields-to-categories.mdx— the Data Preservation section promised values "remain securely stored" but was silent on visibility, which was the part that was broken. Now says they stay on screen, read-only, and how to make one editable again.content/knowledge-base/user-roles-and-their-permissions.mdx— added that Base and Self-service users read custom field values, and disambiguated it from the existing Manage custom fields matrix row (which is about creating definitions in Settings, not reading an asset). New matrix row: Read the custom field values recorded on an asset — true for all four roles.content/knowledge-base/configure-what-self-service-and-base-users-can-see.mdx— the Special Cases bullet named only "the calendar and booking lists". Now names all five surfaces the toggle governs, and adds the Draft exception, which the page never mentioned.content/knowledge-base/adding-assets-and-kits-to-a-booking.mdx— the section on adding items to an active booking mentions the Add to booking option but never said which bookings it offers. Added that, with a link to the permissions article.New content
content/updates/custom-fields-visible-to-view-only-roles.mdx— changelog entry covering both fixes.Review notes
On the changelog threshold. Both are bug fixes, which usually stay below the bar. This one is above it on the data test: for three months Self-service and Base users were shown an asset page with its custom fields silently missing, and no admin had any way to know. Users who noticed and reported it deserve to see it acknowledged; users who assumed the data was never entered need telling that it was. The out-of-category half of the fix hits every role including owners. The booking-picker fix rides along in the same entry rather than getting its own, since it is the same story from the same angle.
No alternatives / solutions / industries sweep. Neither PR adds a capability. Custom fields visible to view-only roles is the documented behaviour being restored, not a new differentiator, and no comparison page could honestly claim an advantage from it. Same for the booking-picker fix. This is the scope-judgment complement to a major-feature rollout.
No pricing data changes. Neither PR touches plan gating. Both roles already held
asset: read; nothing about plan availability moved.No new screenshots. Every page edited is copy-only on a page that already carries its images, so no TODO markers were introduced. The two views that would illustrate this (an asset page as a Self-service user, and a read-only out-of-category field) can't be captured with the current media-pipeline credentials, which are an admin account on the demo workspace. Forcing the second one would mean re-categorizing a real demo asset, which the pipeline is not allowed to do.
Claims traced to source, not to PR bodies:
buildAssetOverviewCustomFieldsinapps/webapp/app/utils/custom-fields.ts— seeded from stored values, topped up with editable definitions, deduped by definition id, sorted by name.if (!hasValue && !canEditField) return null;inassets.$assetId.overview.tsx.canEditField = canEditAsset && isEditable, withisEditablefalse when the definition is absent from the editable set.resolveCanSeeAllBookingsinutils/roles.server.ts, applied inrequirePermission,api+/model-filters.tsandloadBookingsData;bookingDraftVisibilityClause(userId)is AND-ed unconditionally on every booking read path.Checks run locally:
verify-search-coverage(43 routes wrapped) andcheck-product-claims(539 files, no stale claims) both pass. The rendered Cloudflare preview is behind Cloudflare Access and can't be read from a scheduled run, so no visual check was performed.Also seen this run, not acted on
Scan to assign & check outentry point and the2/4 assignedcounter are untouched. Deferred until 1.2.1 ships.Impact scope
Generated by Shelf Content Intelligence — PR→Website Sync
Summary by CodeRabbit