@spree/docs 0.1.299 → 0.1.300

package/dist/api-reference/store.yaml

@@ -11738,7 +11738,7 @@ components:
           type: array
           items:
             type: string
-          description: Subject class names, e.g. ["Spree::Product"] or ["all"]
+          description: Subject short names, e.g. ["product"] or ["all"]
         has_conditions:
           type: boolean
           description: True if the server-side rule has per-record conditions. The

package/dist/developer/dashboard/customization/navigation.md

@@ -22,7 +22,7 @@ nav.add({
   path: '/analytics',      // prefixed with /$storeId at render time
   icon: BarChartIcon,
   position: 650,
-  subject: 'Spree::Order', // optional permission subject — hides item without read permission
+  subject: 'order', // optional permission subject — hides item without read permission
 })
 ```
 
@@ -70,7 +70,7 @@ nav.addChild('products', {
   key: 'products.brands',
   label: 'Brands',
   path: '/products/brands',
-  subject: 'Spree::Brand',
+  subject: 'brand',
 })
 ```
 
@@ -177,7 +177,7 @@ settingsNav.add({
   path: '/integrations/stripe-tax',  // prefixed with /$storeId/settings
   group: 'integrations',
   position: 100,
-  subject: 'Spree::TaxRate',
+  subject: 'tax_rate',
 })
 ```
 

package/dist/developer/dashboard/customization/permissions.md

@@ -33,10 +33,10 @@ interface Permissions {
 It mirrors the backend ability at the **class level**:
 
 ```ts
-permissions.can('read', 'Spree::Order')
+permissions.can('read', 'order')
 ```
 
-Subjects are strings (`'Spree::Order'`, `'Spree::Product'`, or your own `'MyApp::Report'`). There is no client-side record-level check — when a rule is conditional on record attributes, `isConditional` returns `true` and the API is the arbiter: render the control and handle a possible 403.
+Subjects are short names: the model's class name without its namespace, underscored (`'order'`, `'product'`, or `'report'` for your own `MyApp::Report`). Use the `Subject` constants from `@spree/dashboard-core` for Spree's own models. There is no client-side record-level check — when a rule is conditional on record attributes, `isConditional` returns `true` and the API is the arbiter: render the control and handle a possible 403.
 
 ## `subject` shortcut
 
@@ -47,7 +47,7 @@ nav.add({
   key: 'reports',
   label: 'Reports',
   path: '/reports',
-  subject: 'Spree::Order',  // hides nav item without read:Spree::Order
+  subject: 'order',  // hides nav item without read:order
 })
 ```
 
@@ -58,7 +58,7 @@ routes: [{
   key: 'reports',
   path: '/reports',
   component: ReportsPage,
-  subject: 'Spree::Order',
+  subject: 'order',
 }],
 ```
 
@@ -76,7 +76,7 @@ nav.add({
   label: 'Reports',
   path: '/reports',
   if: ({ permissions, store }) =>
-    permissions.can('read', 'Spree::Order') &&
+    permissions.can('read', 'order') &&
     !!(store as Store | null)?.setup_tasks?.every((task) => task.done),
 })
 ```
@@ -94,18 +94,18 @@ import { usePermissions } from '@spree/dashboard'
 
 function ReportsPage() {
   const { permissions } = usePermissions()
-  if (!permissions.can('read', 'Spree::Order')) {
+  if (!permissions.can('read', 'order')) {
     return <Forbidden />
   }
   return <ReportsList />
 }
 ```
 
-The same `permissions` object backs the nav registry's `if` predicate, so you can move logic between the two without changing behaviour. For declarative gating, `<Can I="update" a="Spree::Order">…</Can>` (also from `@spree/dashboard-core`) renders children only when the check passes.
+The same `permissions` object backs the nav registry's `if` predicate, so you can move logic between the two without changing behaviour. For declarative gating, `<Can I="update" a="order">…</Can>` (also from `@spree/dashboard-core`) renders children only when the check passes.
 
 ## Custom permissions
 
-If your customization introduces a new model on the backend, register it as a permission catalog scope there (`Spree.permissions.register_scope` in your engine's initializer). Its keys then appear in the role editor and the API-key scope picker, and any role granted them makes `permissions.can('read', 'MyApp::Report')` resolve in the dashboard exactly like a first-party check — the abilities ship with the current-user response (`GET /api/v3/admin/me`) at sign-in, alongside `permission_keys`, the flat key list the role editor grants from.
+If your customization introduces a new model on the backend, register it as a permission catalog scope there (`Spree.permissions.register_scope` in your engine's initializer). Its keys then appear in the role editor and the API-key scope picker, and any role granted them makes `permissions.can('read', 'report')` resolve in the dashboard exactly like a first-party check — the abilities ship with the current-user response (`GET /api/v3/admin/me`) at sign-in, alongside `permission_keys`, the flat key list the role editor grants from.
 
 ## Reference
 

package/dist/developer/dashboard/customization/routes.md

@@ -135,7 +135,7 @@ routes: [{
   key: 'reports',
   path: '/reports',
   component: ReportsPage,
-  subject: 'Spree::Order',
+  subject: 'order',
 }],
 ```
 

package/dist/developer/dashboard/customization/slots.md

@@ -68,7 +68,7 @@ import { usePermissions } from '@spree/dashboard'
 
 function AdminOnlyMenuItem() {
   const { permissions } = usePermissions()
-  if (!permissions.can('manage', 'Spree::Customer')) return null
+  if (!permissions.can('manage', 'customer')) return null
   return <DropdownMenuItem>…</DropdownMenuItem>
 }
 ```

package/dist/developer/dashboard/recipes/page-action-button.md

@@ -33,7 +33,7 @@ export function SendInvoiceButton({ resource }: Props) {
   })
 
   // Only show to users who can act, and only on completed orders.
-  if (!permissions.can('update', 'Spree::Order')) return null
+  if (!permissions.can('update', 'order')) return null
   if (resource.status !== 'placed') return null
 
   return (
@@ -95,7 +95,7 @@ export function SyncToErpItem({ resource }: Props) {
     successMessage: 'Synced',
   })
 
-  if (!permissions.can('manage', 'Spree::Order')) return null
+  if (!permissions.can('manage', 'order')) return null
 
   return (
     <DropdownMenuItem

package/dist/developer/dashboard/recipes/sidebar-widget.md

@@ -42,7 +42,7 @@ interface Props {
 export function LoyaltyStatusCard({ customer }: Props) {
   const { storeId } = useStore()
   const { permissions } = usePermissions()
-  const canRead = permissions.can('read', 'MyApp::LoyaltyRecord')
+  const canRead = permissions.can('read', 'loyalty_record')
   const { data, isLoading } = useQuery({
     queryKey: ['loyalty', storeId, customer.id],
     queryFn: () =>

package/dist/developer/dashboard/slots-catalog.md

@@ -44,7 +44,7 @@ import { usePermissions, useStore } from '@spree/dashboard'
 function MyWidget({ product }: { product: Product }) {
   const { permissions } = usePermissions()
   const { store } = useStore()
-  if (!permissions.can('read', 'MyApp::LoyaltyRecord')) return null
+  if (!permissions.can('read', 'loyalty_record')) return null
   // ...
 }
 ```

package/dist/developer/upgrades/5.6-to-6.0.md

@@ -506,7 +506,7 @@ If your storefront or webhook receiver reads any of these fields, compare agains
 | `payment_source_type` | Store API payment setup sessions, `payment_setup_session.*` webhooks | `Spree::CreditCard` | `credit_card` |
 | `type` | Custom fields on products, variants, categories and collections | `Spree::CustomFields::ShortText` | removed — read `field_type` (`short_text`) |
 
-The Admin API follows the same rule everywhere: providers and strategies (`fulfillment_provider: 'manual'`, `preferred_order_routing_strategy: 'rules'`), custom field definition `resource_type` (`product`, `category`), tag `taggable_type`, the owner and originator types on records, and filters such as `q[type_eq]=orders`. An integration written against the Admin API preview sends and expects these short names; the [Admin SDK](../sdk/admin/resources.md) types list them.
+The Admin API follows the same rule everywhere: providers and strategies (`fulfillment_provider: 'manual'`, `preferred_order_routing_strategy: 'rules'`), custom field definition `resource_type` (`product`, `category`), tag `taggable_type`, the owner and originator types on records, the permission subjects `/me` returns (`product`, `category`), and filters such as `q[type_eq]=orders`. An integration written against the Admin API preview sends and expects these short names; the [Admin SDK](../sdk/admin/resources.md) types list them.
 
 ## Every event is declared
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@spree/docs",
-  "version": "0.1.299",
+  "version": "0.1.300",
   "description": "Spree Commerce developer documentation for AI agents and local reference",
   "type": "module",
   "license": "CC-BY-4.0",