@spree/docs 0.1.249 → 0.1.251
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
|
@@ -70,4 +70,6 @@ The catalog is deliberately flat: it answers "may this role touch this kind of r
|
|
|
70
70
|
|
|
71
71
|
Every Admin API controller declares its resource (`scoped_resource :orders`). Each request checks the principal's keys — a staff member's role permissions on the current store, or a secret key's scopes — against `read_<resource>` or `write_<resource>` for the action. A missing key produces a 403 naming it — `details.required_permission` for staff, `details.required_scope` for a secret key. Behind that gate, keys compile to CanCanCan rules for record-level concerns, and `GET /api/v3/admin/me` returns both the rule dump the dashboard mirrors and `permission_keys`, the flat key list.
|
|
72
72
|
|
|
73
|
+
Those rules come from `Spree::Ability`. When an application needs CanCanCan rules the catalog cannot express, replace the class with `Spree::Dependencies.ability_class = 'MyApp::Ability'` — subclass `Spree::Ability`, keep its `initialize(user, options = {})` signature (`options[:store]`, and `options[:resource]` for a seller panel), and add `can` / `cannot` rules after `super`. The Admin and Seller APIs build every staff ability from it; secret API keys use `Spree::ApiKeyAbility` and never consult it.
|
|
74
|
+
|
|
73
75
|
Storefront customers are not part of this system — customer authorization is ownership, enforced by the Store API's scoped lookups, with nothing to configure. The one swappable piece is `Spree::Storefront::AccessPolicy` (via `Spree::Dependencies.storefront_access_policy_class`): a generic `readable?` / `writable?` / `scope` protocol that defaults to "the caller owns the record", with carts and orders adding guest-token access. Replace it only when access must widen beyond the owner, such as company accounts sharing purchases or wishlists.
|
|
@@ -391,6 +391,20 @@ one. An order whose every parcel was recalled now reads
|
|
|
391
391
|
`fulfillment_status: unfulfilled` rather than `canceled`; only a canceled
|
|
392
392
|
order reads `canceled`.
|
|
393
393
|
|
|
394
|
+
## Payment source IDs use the `psrc_` prefix
|
|
395
|
+
|
|
396
|
+
`Spree::PaymentSource` shared the `ps_` prefix with `Spree::PaymentSession`,
|
|
397
|
+
so the same string could name either record. Payment sources now use
|
|
398
|
+
`psrc_`. The encoded part of the ID doesn't change, only the prefix. The only
|
|
399
|
+
place a payment source's ID shows up is the `source_id` of a payment backed by
|
|
400
|
+
a non-card payment source (wallets, bank redirects and similar). If you stored
|
|
401
|
+
one of those values, swap `ps_` for `psrc_`. Payment session IDs stay `ps_`.
|
|
402
|
+
|
|
403
|
+
Class-level `decode_prefixed_id` (for example `Spree::Product.decode_prefixed_id`)
|
|
404
|
+
now returns `nil` for an ID with another model's prefix, the same as
|
|
405
|
+
`find_by_prefix_id`. Call `Spree::PrefixedId.decode_prefixed_id` if you
|
|
406
|
+
really need to decode any prefix.
|
|
407
|
+
|
|
394
408
|
## Removed in 6.0
|
|
395
409
|
|
|
396
410
|
These were deprecated in 5.x and are **gone now** — there is no bridge, so calls raise `NoMethodError`. Most were one-line delegations to a replacement that already exists.
|