Hello Christian,
"May I kindly ask you to create a separate ticket?"
Sure, sorry for mixing up these topics. I will create that ticket. Can I reference this one so that it is clear that someone is already "working on" our staging site?
Let me know if that's okay with you and I will try with Duplicator Pro.
It is okay, I just need to prepare a new exact clone of our production site. I have my own bash script to clone to the subdomain which copies all files (except for wp-config.php, .htaccess and such...) and uses wp-cli to migrate the database too. I've been using it for years and I'm confident it works well meaning it does create an exact clone. Afterwards you can use Duplicator Pro to clone it to your environment.
Is that okay this way?
Regards,
G
Hello Christian,
I have just finished with cloning the current state of the production site to the staging subdomain.
Thank you in advance,
G
Sure, sorry for mixing up these topics. I will create that ticket. Can I reference this one so that it is clear that someone is already "working on" our staging site?
Of course, feel free to provide a link in the other ticket.
It is okay, I just need to prepare a new exact clone of our production site.
Okay great, let me know how to access the staging site and I will begin making a Duplicator clone. Private reply fields here.
Hi, I've been able to replicate this solution 4 times consistently in my local environment. It requires updating WooCommerce to the latest version, 3.2.1. Is there a reason you have chosen not to update yet?
1. Note all the current Access settings, as yours will be wiped out.
2. Update WC to 3.2.1, then refresh the plugins page.
3. In the purple "WooCommerce data update" notification, click "Run DB updater"
4. Toolset > Settings > Access, click "Remove Access settings from my database". The check "Remove Access settings from the database" in the checkbox list and click "Reset Access settings"
5. Toolset > Access Control > Post Types > Posts panel - click "Managed by Access" and save.
6. Still in Toolset > Access Control > Post Types, Open the Email Logs panel, select "Managed by Access" and click save.
7. Log in as the Shop Manager and you can access the logs dashboard.
Thank you very much, Christian!
Tomorrow morning I will have time to try it out. I will report back.
"It requires updating WooCommerce to the latest version, 3.2.1. Is there a reason you have chosen not to update yet?"
I did not have time to do it and I'm always super cautious with important updates like WooCommerce itself. Also, I normally wait for about a week before I apply an update. This is to let others on the globe to test them before I consider it safe to do it. Normally I do it on a staging site and re-do it on production. Kinda time consuming, so I need to find the right time...
Regards,
G
I understand - I'll mark this ticket as pending an update from you and we can pick up when you have a chance to test this out thoroughly.
Hello Christian,
We have partial success but no good news I'm afraid.
I upgraded WooCommerce and did all the steps afterwards and it did indeed work but... What I mean by "but" is this:
- We have a custom role called "Fulfillment Specialist" and even if I ticked access for them (along with Shop Manager), they were NOT given access to Email Logs, only Shop Managers.
- And even Shop Managers are only given access to Email Logs at Step 6 of yours. After Step 7, I also turned on "Managed by Access" for "Pages" too, and after doing so, Shop Managers are NO LONGER given access to Email Logs, meaning we are back to the beginning, the issue is not solved unfortunately, because it is not possible to restore my previous Access settings as doing so breaks it again.
Just a side note: by upgrading to WooCommerce 3.2.1 the site was hit by this bug: versteckter Link
I had to manually apply the patch to fix it. I hope no more hidden bugs will emerge...
Back to our issue: I'm beginning to think that there are fundamental issues with Access. Just by turning on "Managed by Access" for Pages should not mess up other permissions of other post types in the system. This sounds like a serious bug to me.
For the time being I need stop dealing with this issue. We are not happy that Email Logs cannot be accessed by those managing the shop but I do not have more time to put into it. I hope you can fix Access as soon as possible. I have already spent a day or so on this issue.
Regards,
Gabor
Sorry to hear you're still having problems with this. I can escalate this to our 2nd tier support team for additional investigation. I checked the plugin's page on wordpress.org and I see the following information:
...Log emails to the WordPress database for later analysis. Access is restricted to administrators, and emails with WordPress passwords are obfuscated for security / privacy...
https://wordpress.org/plugins/log-emails/
So by design, it appears the Log Emails plugin is not set up to allow access to these logs to any role other than Administrator. It may be the case that Access simply cannot override these settings effectively, and the solution may require collaboration with the developers of this plugin. I will submit the issue to the team and ask for more information, and keep you updated here.
Thank you for your help Christian!
I'm no expert in this but in the plugin's source code I can only find this bit which is related to access permissions:
if (!current_user_can($post_type->cap->edit_posts)) {
wp_die(sprintf('<h1>%s</h1><p>%s</p>',
__('Cheatin’ uh?', 'log-emails'),
__('You are not allowed to view email logs.', 'log-emails')), 403);
}
And this blocks users without edit post permissions only as far as I know. Other than that I could not find anything. Maybe my limited knowledge in this field prevents me from finding more. Also, the message which shows up is not this one but a general one found in the core.
Also, I have a backup of the site where it used to work but later at some point in time – after several updates to the system and plugins –, I noticed that it stopped working. Maybe it should not have worked in the fist place(?) and things have just been "fixed"? That would be strange but anything is possible in computing, I think...
Any help is appreciated. if you think it helps , I can upload the "working version" to the staging site so that you can take a look at it.
Thanks for the additional info. If it's easy for you to put the working version up on the dev1 site, that would be very useful for comparison. I can log in and create a clone when you're ready.
Hello,
Thanks for the additional help, I really appreciate it! I've just replaced the dev1 site with the one form July. Please check the fulfillment test user as well as they should see the email logs as well.
Regards,
G
I have some new information from our 2nd tier support team. It appears that the Log Emails plugin registers its own post type, and includes capabilities based on the WordPress capability "activate_plugins". See \plugins\log-emails\includes\class.LogEmailsPostTypeLog.php:
public function register() {
// register the post type
register_post_type(self::POST_TYPE, array(
...
'capabilities' => array (
'create_posts' => 'do_not_allow',
'edit_post' => 'activate_plugins',
'edit_posts' => 'activate_plugins',
'edit_others_posts' => 'activate_plugins',
'delete_post' => 'activate_plugins',
'delete_posts' => 'activate_plugins',
'read_post' => 'activate_plugins',
'read_private_posts' => 'do_not_allow',
'publish_posts' => 'do_not_allow',
),
...
));
}
This means that in order to enable Email Logs for your Shop Manager user, you must enable the "activate_plugins" capability in Access Control for the Shop Manager role. It would be great if the Log Emails plugin would fix this and apply the standard permissions here. Otherwise, you must allow your Shop Managers to activate plugins in order to provide access to the email logs as well, since these rules are intermingled.
Thanks Christian, Nigel and your colleagues for pointing me in the right direction! I have found the solution. There is a hook called register_post_type_args:
https://developer.wordpress.org/reference/hooks/register_post_type_args/
which can be used to change the values, so I use this:
add_filter('register_post_type_args', 'site_log_emails_capabilities', 10, 2);
function site_log_emails_capabilities($args, $post_type){
if ($post_type == 'log_emails_log'){
$args['capabilities']['edit_post'] = 'manage_woocommerce_orders';
$args['capabilities']['edit_posts'] = 'manage_woocommerce_orders';
$args['capabilities']['edit_others_posts'] = 'manage_woocommerce_orders';
$args['capabilities']['delete_post'] = 'manage_woocommerce_orders';
$args['capabilities']['delete_posts'] = 'manage_woocommerce_orders';
$args['capabilities']['read_post'] = 'manage_woocommerce_orders';
}
return $args;
}
Since both user groups of Custom Roles have the manage_woocommerce_orders capability, this is the one I chose. Note that I had to change all six capabilities even though I only want to give view access and not anything else. This is because without all these 6 changes the users were still blocked. I do not understand why... However, this way they only get view access which is what I need anyway.
Roles and capabilities are not the easiest part in WordPress to work with...
Thanks once more. At least I have learnt a few things along the way but I still do not know what caused the change in the first place. The Email Logs plugin did not change for sure. Access and WordPress did.
We can close this ticket.
Have a nice day,
G
