← All changes | includes/API/V2/Write_Controller.php +7 -102 1.10.17 → 1.10.18 View file →

		@@ -7,9 +7,9 @@
7	7
8	8	namespace WCPOS\WooCommercePOS\API\V2;
9	9
10	10	use WCPOS\WooCommercePOS\API\V2\Writers\Collection_Writer_Resolver;
11		-use WCPOS\WooCommercePOS\Services\Customer_Account_Guard;
	11	+use WCPOS\WooCommercePOS\Services\Permission_Rules;
12	12	use WCPOS\WooCommercePOS\Services\Tax_Id_Types;
13	13	use WCPOS\WooCommercePOS\Sync\Api;
14	14	use WCPOS\WooCommercePOS\Sync\Collections;
15	15	use WCPOS\WooCommercePOS\Sync\Endpoint_Permissions;
		@@ -44,14 +44,8 @@
44	44	* live in an injected mutation store, so the apply logic is unit-testable with a
45	45	* fake store + a stubbed `rest_do_request`.
46	46	*/
47	47	class Write_Controller extends WP_REST_Controller {
48		- /**
49		- * True while wc_rest_check_user_permissions() is re-run for a cleared target.
50		- *
51		- * @var bool
52		- */
53		- private $rejudging_user_target = false;
54	48
55	49	// Our gate (capability + F13 health); forwarded writes scope the client-tier grant below.
56	50	use Endpoint_Permissions;
57	51
		@@ -599,13 +593,13 @@
599	593	*
600	594	* @param int $id The order id.
601	595	*/
602	596	private function can_forward_delete( int $id ): bool {
603		- add_filter( 'woocommerce_rest_check_permissions', array( $this, 'wcpos_check_permissions' ), 10, 4 );
	597	+ Permission_Rules::install_wc_filter();
604	598	try {
605	599	return (bool) wc_rest_check_post_permissions( 'shop_order', 'delete', $id );
606	600	} finally {
607		- remove_filter( 'woocommerce_rest_check_permissions', array( $this, 'wcpos_check_permissions' ), 10 );
	601	+ Permission_Rules::uninstall_wc_filter();
608	602	}
609	603	}
610	604
611	605	private function checkpoint_and_finalize( string $mutation_id, int $remote_id, int $response_status ) {
		@@ -751,9 +745,9 @@
751	745	*/
752	746	private function dispatch_write( WP_REST_Request $request ) {
753	747	// Stamp here so direct callers (notably deletes) carry the scope too.
754	748	Store_Scope::stamp( $request );
755		- add_filter( 'woocommerce_rest_check_permissions', array( $this, 'wcpos_check_permissions' ), 10, 4 );
	749	+ Permission_Rules::install_wc_filter();
756	750	try {
757	751	// Marked as OUR traffic for the duration of the forward, so a consumer
758	752	// keyed on store scope can act on a till write without also claiming
759	753	// every stock wc/v3 product write on the site (pro#425 review).
		@@ -762,104 +756,15 @@
762	756	return rest_do_request( $request );
763	757	}
764	758	);
765	759	} finally {
766		- remove_filter( 'woocommerce_rest_check_permissions', array( $this, 'wcpos_check_permissions' ), 10 );
	760	+ Permission_Rules::uninstall_wc_filter();
767	761	}
768	762	}
769	763
770		- /**
771		- * Judge a customer edit or delete the way V1\Customers_Controller does.
772		- *
773		- * The staff guard runs first and is final. A target it has cleared is then
774		- * re-judged by WooCommerce with the target's own roles allowed through the
775		- * shop_manager role-name restriction, so a shop manager can edit a subscriber
776		- * from a current app exactly as from the legacy route. WooCommerce's
777		- * credential fence is untouched: it runs in the controller, not here.
778		- *
779		- * @param bool $permission WooCommerce's verdict so far.
780		- * @param string $context 'edit' or 'delete'.
781		- * @param int $target_id Target user ID.
782		- */
783		- private function check_user_permission( bool $permission, string $context, int $target_id ): bool {
784		- if ( $this->rejudging_user_target ) {
785		- return $permission;
786		- }
787		- if ( ! Customer_Account_Guard::can_modify( get_current_user_id(), $target_id ) ) {
788		- return false;
789		- }
790		- if ( $permission ) {
791		- return true;
792		- }
793		- $this->rejudging_user_target = true;
794		- $restore = Customer_Account_Guard::allow_target_roles( $target_id );
795		- try {
796		- return (bool) wc_rest_check_user_permissions( $context, $target_id );
797		- } finally {
798		- $restore();
799		- $this->rejudging_user_target = false;
800		- }
801		- }
802		-
803		- /**
804		- * Authorize proxied mutations for POS users while protecting staff accounts.
805		- *
806		- * This filter is attached only while a sync push is forwarded to wc/v3, so
807		- * direct WooCommerce requests keep their normal permission checks.
808		- *
809		- * @param bool $permission The current permission.
810		- * @param string $context The request context.
811		- * @param int $object_id The object ID.
812		- * @param string $post_type The object type passed by WooCommerce.
813		- *
814		- * @return bool
815		- */
	764	+ /** @deprecated Use Permission_Rules::wc_filter(). */
816	765	public function wcpos_check_permissions( $permission, $context, $object_id, $post_type ) {
817		- // Customer edits/deletes: the staff guard is final, then a cleared target
818		- // is judged by WooCommerce the same way the v1 controller judges it.
819		- if ( 'user' === $post_type && (int) $object_id > 0 && \in_array( $context, array( 'edit', 'delete' ), true ) ) {
820		- return $this->check_user_permission( (bool) $permission, $context, (int) $object_id );
821		- }
822		-
823		- // Catalog and coupon WRITES require the user's real WooCommerce
824		- // capabilities — no POS-tier widening. The cashier role is deliberately
825		- // read-only on catalog (Activator), and a blanket grant here handed
826		- // every POS user product deletion and coupon minting. Product decision
827		- // 2026-08-06: strict wc/v3 parity for catalog mutations; only the
828		- // HPOS placeholder remap below (orders) adjusts anything, and it never
829		- // grants beyond the user's own role caps.
830		-
831		- // Orders: with HPOS enabled (sync off), get_post() yields shop_order_placehold
832		- // (map_meta_cap = false, no capability_type), so WooCommerce's REST check maps
833		- // to the generic edit_post/delete_post caps that cashier-tier roles lack —
834		- // even though they hold the real shop_orders caps. Re-check the capability the
835		- // mapping SHOULD have produced, mirroring V1\Orders_Controller's
836		- // update_item_permissions_check fix. No grant beyond the user's own role caps.
837		- if ( ! $permission && 'shop_order' === $post_type ) {
838		- $order_caps = array(
839		- 'read' => 'read_private_shop_orders',
840		- 'create' => 'publish_shop_orders',
841		- 'delete' => 'delete_shop_orders',
842		- );
843		- $order_cap = $order_caps[ $context ] ?? null;
844		- // edit and delete are ownership-sensitive: the base *_shop_orders cap only
845		- // authorizes acting on the user's OWN orders. Touching another user's order
846		- // additionally requires the *_others_shop_orders cap, mirroring WooCommerce's
847		- // own meta-cap map. Without this, a cashier with delete_shop_orders (but not
848		- // delete_others_shop_orders) could delete/void orders they do not own.
849		- if ( \in_array( $context, array( 'edit', 'delete' ), true ) ) {
850		- $order_post = get_post( $object_id );
851		- if ( $order_post ) {
852		- $owns_order = get_current_user_id() === (int) $order_post->post_author;
853		- $order_cap = $owns_order ? "{$context}_shop_orders" : "{$context}_others_shop_orders";
854		- }
855		- }
856		- if ( $order_cap && current_user_can( $order_cap ) ) {
857		- $permission = true;
858		- }
859		- }
860		-
861		- return $permission;
	766	+ return Permission_Rules::wc_filter( $permission, $context, $object_id, $post_type, 'writes' );
862	767	}
863	768
864	769	/**
865	770	* Read this collection's document for one record, through its writer.