Great but…

Hi Brygger,

Thank you for you feedback.

Lets see if we can get this sorted out. Can you help me out with some more details? Like error messages etc.

Maybe we could add a star or two more to your rating afterwards ??

Hi there.

I’ve been communicating with the developer of Press Permit who has helped me troubleshooting my problem. The PP plugin adds advances permissions features to my wp-site. After an WooCommerce upgrade, it broke some of the permissions so my users cannot do their daily work.

We’re a non profit organisation taking care of stray and homeless cats, finding new homes for them and treating them for diseases etc. Our users use the site to login and create new custom posts with the new cats looking for new homes and to write small posts with news etc. They must not be able to have access to the admin functions of wp. But at the moment they cannot see their own posts with the custom permissions. Only with admin they are able so create, edit and publish these custom posts.

The Press Permit developer has found that disabling WooCommerce Quick Pay will make permissions work again. And it corresponds to the time when we updated, that it began to go wrong.

This code snippet from woocommerce-quickpay.php is making the trouble (I’ve been told):

public function handle_bulk_actions() {
            $wp_list_table = _get_list_table( 'WP_Posts_List_Table' );

            $action = $wp_list_table->current_action();

            // Check for posts
            if ( ! empty( $_GET['post'] ) ) {
                $order_ids = $_GET['post'];

                // Make sure the $posts variable is an array
                if ( ! is_array( $order_ids ) ) {
                    $order_ids = array( $order_ids );
                }
            }

            if ( current_user_can( 'manage_woocommerce' ) ) {
                switch ( $action ) {
                    // 3. Perform the action
                    case 'quickpay_capture_recurring':
                        // Security check
                        $this->bulk_action_quickpay_capture_recurring( $order_ids );
                        break;
                    default:
                        return;
                }
            }

            // 4. Redirect client
            wp_redirect( $_SERVER['HTTP_REFERER'] );
            exit;
        }

I’m not that into php-coding but can recognise a pattern in the Pres Permit developers finding.

It would be very nice if this was fixed because we’re really depending on both WooCommerce and Press Permit functions in our daily work.

Regards
Kaspar Brygger
[ Signature moderated ]

• This reply was modified 7 years, 8 months ago by brygger.
• This reply was modified 7 years, 8 months ago by Steven Stern (sterndata).

We’re seeing the same issue on a site that uses WooCommerce and WooCommerce QuickPay. Users with the role editor do not have the ‘manage_woocommerce’ capability, and are therefore redirected back to the referer whenever they go to edit.php for any post type.

I’m guessing that the idea behind the redirect is to send the user back after a bulk update if the action is ‘quickpay_capture_recurring’, but currently it happens every time for users without the ‘manage_woocommerce’ capability on the ‘load-edit.php’ action.

So the following might be more appropriate?

        public function handle_bulk_actions() {
	        $wp_list_table = _get_list_table( 'WP_Posts_List_Table' );

	        $action = $wp_list_table->current_action();

	        // Check for posts
	        if ( ! empty( $_GET['post'] ) ) {
		        $order_ids = $_GET['post'];

		        // Make sure the $posts variable is an array
		        if ( ! is_array( $order_ids ) ) {
			        $order_ids = array( $order_ids );
		        }
	        }

	        if ( current_user_can( 'manage_woocommerce' ) ) {
		        switch ( $action ) {
			        // 3. Perform the action
			        case 'quickpay_capture_recurring':
				        // Security check
				        $this->bulk_action_quickpay_capture_recurring( $order_ids );

				        // 4. Redirect client
				        wp_redirect( $_SERVER['HTTP_REFERER'] );
				        exit;
			        default:
				        return;
		        }
	        }

        }

Our workaround for now has been to make all the users on that site administrator, but that requires a certain level of trust.

FYI this problem has been confirmed and a fix is already prepared for the next release.

This issue has been fixed in 4.8.3.