[AGB]

Hi Vladimir,
I replaced our 4.28.2 version with the development version 4.29.b4 (on a testing site). Immediately the issue was resolved – awesome; thanks! To initially test, I simply blocked all the Posts menu items again, via the Admin Menu module (for the affected roles). Those roles no longer see the Posts menu item, and are still able to filter WC orders by Date, Customer, etc. Great!

I remain curious about one thing: you mention that ‘edit_posts’ capability is not required to allow work with WC Orders. Recently during development, I think I had our internal roles set up like that (at least briefly). Those roles could Add/Create orders without any Posts capability. We are now on live site (launched yesterday) and all plugin versions & usage are same as before. However now these internal roles cannot Create orders unless I give them ‘edit_posts’ AND ‘create_posts’ capabilities. I’m not sure why. Also it is not really a problem now for daily operations, once we can put 4.29.b4 “stable” version on live site… But I want to figure out how to Not have those Posts capabilities enabled, since I have to then block them.

For example, our Sales role has the following WC capabilities allowed:

create_shop_orders
edit_others_shop_orders
edit_published_shop_orders
edit_shop_order
edit_shop_orders
manage_woocommerce
publish_shop_orders
read_shop_order

They also have general ‘read’ of course, and have ability to ‘create_users’, ‘edit_users’ and ‘list_users’ as well.

With that setup… (plus usage of Admin Menu and Meta Boxes modules to deny additional things)… they cannot Add New Order. IF I also apply those two Posts capabilities (edit and create), then they are able to Add New Orders.

Please let me know why this may be? Thank you!

[AGB]

Great; thanks again. I will try it out!

[AGB]

Thanks Vladimir – today the update worked fine.

[AGB]

Hi Vladimir,
We were also getting that error earlier today. We just tried again but we get the same error.

[AGB]

Perfect recipe. Thanks Vladimir!

[AGB]

Got it! I appreciate the clarification – all is working great now. Thanks for your prompt replies!

[AGB]

YES! This is perfect – thank you so much. One last question, regarding syntax: to apply this to multiple roles (‘sales’ role and also ‘shipping’ role), do I simply use a comma as the separator? Or would that make it apply to someone who had both sales & shipping role?

For example would this line be correct for applying to each of the two roles:
if (!current_user_can(‘sales’,’shipping’))

[AGB]

Thank you – that was successful hiding the Resend Order Emails option “Refunded Order”, in the Order Actions drop-down.

However the role can still select “Refunded” in the Order Status drop-down. Then if the role saves order, it will update order totals as being fully refunded.

Now I wonder though: if I did hide that “Refunded” order status option for role, then would it cause problem if role was viewing an old order that was previously refunded – meaning would its order status be missing/show blank?

I want to keep using your code above… Then instead of also trying to hide Refunded order status from drop-down… is it better or possible to restrict role from Saving the order IF he has “Refunded” as selected status option? So if he tried to save with that status, he’d get the message popup that he doesn’t have the permissions. I think that’d be ideal.

I really appreciate your help on this.

[AGB]

Thank you Vladimir for consistently providing such great support! That worked perfectly to hide the Refund button from showing for the role (sales) we specified in the code. However, in General Details part of order edit form, that role still has the ability to set the Order Status to be “Refunded”, which when saving order will proceed to change the order details, reflecting a full refund for whole order (products + shipping).

Is it also possible to hide (or block ability to select) the “Refunded” status from the Order Status drop-down in order edit form, for this particular role?

Thanks again.

[AGB]

Perfect; thank you Vladimir. Just what I needed.

[AGB]

Hi Vladimir, we had that problem with the YITH menu item, and the code you provided here fixed it (thanks)! However we are having the same issue with another plugin, the Vehicle Parts Finder. It remains as an empty menu item for roles that aren’t allowed access.

Can you please help by explaining how we may adjust that code to apply to this VPF plugin? Can yit_menu_fix simply be changed to vpf_menu_fix in both places? And change ‘yit_plugin_panel’ to ‘vpf_makes’?

(By inspecting code for YITH menu item, I found class and id of the li tag to be “toplevel_page_yit_plugin_panel”. For VPF menu item, it is “toplevel_page_vpf_makes”, so that is where I got that term from.)

Thanks so much.

[Author]

Posts