content: what Self-service and Base users can see (shelf.nu#2824, #2792)

content/knowledge-base/adding-assets-and-kits-to-a-booking.mdx

@@ -3,7 +3,7 @@ title: "Adding Assets and Kits to a Booking"
 description: "This guide explains how to add equipment to a booking in Shelf, covering the process for adding both individual assets and pre-configured kits to time-based check-outs."
 category: "Bookings & Custody"
 date: "2024-06-01"
-updated: "2026-08-07"
+updated: "2026-08-10"
 layout: "knowledge-base"
 ---
 
@@ -61,6 +61,8 @@ You don't have to finalize the whole list before checkout begins. You can add as
 
 Items added to an active booking join it as line items and stay **Available** until you check them out. They aren't force-checked-out just because the booking is already underway, which fits the [progressive checkout](/knowledge-base/progressive-checkout-of-bookings) flow where gear leaves in stages. The only thing you can't add is an item that's already checked out on another active booking, since that would double-book it.
 
+Which bookings the **Add to booking** picker offers follows the workspace's booking-visibility setting, the same rule the **Bookings** index and the command palette use. Self-service and Base users are shown their own bookings by default, and every booking in the workspace except other people's **Drafts** once an admin switches the setting on in **Settings ▸ Workspace ▸ Permissions**. A booking still in Draft is only ever visible to the person who created it, whatever the setting says. The list stays the same whether you scroll it or type to search it. See [Configure What Self-service and Base Users Can See](/knowledge-base/configure-what-self-service-and-base-users-can-see).
+
 Checking a late addition out works the same three ways as anything else on the booking: **Check out remaining** from the checkout button, scanning it with **Scan to check out**, or ticking its row and using **Actions → Check out selected items**. That holds whether the booking was originally checked out item by item or all at once with the **Check out** button, and it applies to quantity-tracked lines as well as individual assets.
 
 ## Finding and sorting assets on a booking

content/knowledge-base/configure-what-self-service-and-base-users-can-see.mdx

@@ -3,7 +3,7 @@ title: "Configure What Self Service and Base Users Can See"
 description: "Administrators can customize permission settings in Shelf to control what Self Service and Base users can see regarding custody and booking information for assets, allowing for precise control over team member access."
 category: "Bookings & Custody"
 date: "2024-06-01"
-updated: "2026-04-09"
+updated: "2026-08-10"
 layout: "knowledge-base"
 ---
 
@@ -38,7 +38,8 @@ This feature has been carefully designed to handle special cases:
 
 - Users can always see custody and booking information for assets assigned to them, regardless of their role.
 - When custody visibility is disabled, Self Service and Base users will see a "Private" badge instead of custodian names on asset lists.
-- Without booking visibility permissions, users will only see their own bookings in the calendar and booking lists.
+- Without booking visibility permissions, users will only see their own bookings. That applies everywhere bookings are listed or searched: the **Bookings** index, the calendar, the command palette, a workspace data export, and the **Add to booking** picker on an asset or kit page. Turn the toggle on and all five surfaces open up together, so a booking a user can find in one place is a booking they can find in the others.
+- Draft bookings are the one exception the toggle never reaches. A booking still in **Draft** is visible only to the person who created it, whatever the setting says.
 
 ## Why This Matters
 

content/knowledge-base/editing-asset-fields-inline.mdx

@@ -3,7 +3,7 @@ title: "Editing Asset Fields Inline"
 description: "Edit asset fields directly from the asset detail page in a single click — no need to open the full edit form. Covers what's editable inline, who can do it, and how it interacts with custom fields and validation."
 category: "Assets"
 date: "2026-05-08"
-updated: "2026-05-08"
+updated: "2026-08-10"
 layout: "knowledge-base"
 ---
 
@@ -40,7 +40,7 @@ For everything else (name, primary image, QR code, etc.) the **Edit** button on
 
 All custom fields configured for the asset's category appear in a single alphabetically-sorted list on the asset page. Fields that have a value show their value with a pencil icon for editors; fields that don't yet have a value show **Not set** with the same pencil icon. Field positions stay stable as you fill them in — no jumping around when values are added or cleared.
 
-If you change the asset's **Category**, the custom fields list refreshes to match the new category's definitions. Values for fields that exist in both the old and new category are preserved; fields that only exist in the old category are no longer shown but are not deleted.
+If you change the asset's **Category**, the custom fields list refreshes to match the new category's definitions. Values for fields that exist in both the old and new category are preserved. A value left behind by a field that only belongs to the old category is still shown, but read-only: it has no pencil icon, because saving to a field outside the asset's current category is rejected. Re-assign the asset to that category to make the field editable again.
 
 See: [Adding Additional Fields to Assets](/knowledge-base/adding-additional-fields-to-assets) for setting up custom fields on a category.
 
@@ -49,7 +49,7 @@ See: [Adding Additional Fields to Assets](/knowledge-base/adding-additional-fiel
 Inline editing follows the same permissions model as the full edit form:
 
 - **Owners and Admins** see and can edit every field
-- **Self-service users and Base users** see only fields with values; they cannot enter edit mode
+- **Self-service users and Base users** see every custom field that has a value, read-only. Fields still sitting at **Not set** are hidden from them, since there is nothing to read and nothing they can fill in.
 
 Editors who don't have permission to update a particular field will not see the pencil icon for that field.
 

content/knowledge-base/linking-custom-fields-to-categories.mdx

@@ -3,7 +3,7 @@ title: "Linking Custom Fields to Categories"
 description: "Configure custom fields for your asset categories and start enjoying a more streamlined asset management experience in Shelf."
 category: "Custom Fields"
 date: "2024-06-01"
-updated: "2026-04-14"
+updated: "2026-08-10"
 layout: "knowledge-base"
 ---
 
@@ -45,6 +45,8 @@ The configured custom field dynamically appears when creating or editing assets
 
 When changing an asset's category, previously attached custom field values remain securely stored. Switching categories and reverting later preserves custom field data, ensuring continuity. These values are included in database backups and exports for added data integrity assurance.
 
+They also stay on screen. A value written while the asset belonged to another category still appears in the custom fields list on the asset page, marked read-only with no pencil icon, so nothing you recorded disappears from view just because the category moved on. To edit that value again, put the asset back in the category the field is linked to.
+
 ## Related Articles
 
 - [Custom Field Types in Shelf](/knowledge-base/custom-field-types-in-shelf)

content/knowledge-base/user-roles-and-their-permissions.mdx

@@ -3,7 +3,7 @@ title: "User Roles and Their Permissions"
 description: "See what each Shelf user role can do — a full permissions matrix for Owner, Administrator, Self-service and Base, plus how to restrict who books equipment."
 category: "Team"
 date: "2024-06-01"
-updated: "2026-08-06"
+updated: "2026-08-10"
 layout: "knowledge-base"
 ---
 
@@ -37,7 +37,7 @@ The most common question — especially for universities and multi-department te
 2. **Hide other people's gear** — leave **custody visibility** and **booking visibility** off (the default) and Base/Self-service users see only what they're involved with. Flip them on when you'd rather everyone see who has what. Both live in **Settings ▸ Workspace ▸ Permissions** — no need to leave this for another page, though there's a [full walkthrough with screenshots](/knowledge-base/configure-what-self-service-and-base-users-can-see) if you want it.
 3. **Separate departments entirely** — give each department its own **workspace**. Assets, members, and roles are fully isolated between workspaces.
 
-Asset notes stay with Admins and Owners regardless of those toggles. Base and Self-service users can open an asset and see its details, but the **Activity** tab, which holds the notes and the last-scan record, is not shown to them at all. Audit activity is different: every role can read audit notes, so the Activity tab on an audit stays visible.
+Asset notes stay with Admins and Owners regardless of those toggles. Base and Self-service users can open an asset and see its details, including every **custom field** that has a value, read-only. Being unable to *manage* custom fields is about creating and editing definitions in Settings, not about reading what an asset records. What is not shown to them is the **Activity** tab, which holds the notes and the last-scan record. Audit activity is different: every role can read audit notes, so the Activity tab on an audit stays visible.
 
 <Callout type="takeaway" title="Honest note for evaluators">
 Shelf's roles are **fixed rather than fully custom** — there's no per-person role editor, and access is granted by role and workspace, not asset-by-asset. The three levers above cover the vast majority of "restrict who can touch what" setups. If you have a specific structure in mind, [book a demo](/demo) and we'll map it to the right mix of roles, toggles, and workspaces.
@@ -93,6 +93,7 @@ Every checkmark is what the role can actually do in Shelf today.
   headers={["Owner", "Administrator", "Self-service", "Base"]}
   rows={[
     { label: "View and search assets", values: [true, true, true, true] },
+    { label: "Read the custom field values recorded on an asset", values: [true, true, true, true] },
     { label: "View an asset's Activity tab (notes and scan history)", values: [true, true, false, false] },
     { label: "Add, edit and delete assets", values: [true, true, false, false] },
     { label: "Import and export asset data", values: [true, true, false, false] },

content/updates/custom-fields-visible-to-view-only-roles.mdx

@@ -0,0 +1,18 @@
+---
+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.