RLDD

I believe this scenario to be resolved in v3.0.18 = * Bug fix to cart refresh on update. This will force a refresh in the classic cart (because WC does not facilitate an easier method). But the new cart blocks will pick up coupon changes automatically upon changes to the cart.

Hi ucarman2002,

I was able to verify a coupon auto applied in the cart on your site. I also checked another test site to ensure there have been no changes to the way the plugin interacts with the WooCommerce cart.

Note that if you have previously removed a coupon from the cart, it won’t auto apply again until the coupon cache is reset. I recommend using another session (like a private/incognito tab) to test functionality.

The options to reset coupon cache and troubleshoot are available at WooCommerce > Auto Coupons > Status. If you continue to experience an issue, please visit Upgrade > Contact Support to provide diagnostics.

We have tested in more depth and determined that this scenario can occur when there are various caching plugins or server side caching enabled. If caching is turned off, the plugin performs as intended.

Auto Coupons is always looking for a page load of the cart to auto-apply coupons. If caching plugins load the cart page from the cache instead of actually reloading the cart, auto-apply won’t be triggered.

I recommend disabling caching on most WooCommerce pages, at the very least on the cart and checkout pages. Some caching plugins will offer to support different rules between mobile and desktop, these should be the same. Also, be wary of Redis Object Cache or WP Redis – this type of caching would be fine for a blog or search, but not a cart or checkout.

Let me know what you find and if this resolves your issue.

Hi there,

Thank you for your report. The behavior you have described is by design to prevent an uninterruptible cycle. The coupon will auto-apply once. If the coupon is subsequently removed, it will not auto-apply again -to prevent an infinite cycle where a previously removed coupon is automatically applied on every page load. A coupon set to auto-apply and manually removed will apply again if another coupon is added and removed.

The coupon cache will attempt to use a cookie, but if there is none available it will use the IP. That may be why the behavior appears to be different on iOS or in private tabs.

Over 99% of auto-applied promotions will not be removed by the customer, so this issue will rarely surface outside of testing, but if you have any suggestions to improve this behavior please let me know.

Hi Eric,

Ok, I understand now. Can you contact us through the Support button at the top right on the plugin admin page? This will provide us with the root domain and help us resolving the licensing issue. It’s a quick fix, but it’s information I can’t ask for in a public thread.

Hi Eric,

Yes most browsers will allow 1 minute intervals after clicking into the time field, even after restrictions are added. This is because the browser renders the time field and it may appear different between Edge, Chrome and Firefox. The behavior changes based on the field in different browsers – and between mobile and desktop versions. Attempting to restrict the time has different results in different browsers, so we’ve decided to let the browser render it without restrictions.

For itemized entries, the plugin offers up and down arrows next to the time entry fields that increment the time input by 15 minutes. There is also similar behavior for the ‘simple total’ entry type.

Hello,

I’m happy to help you with roles for Dynamic Time. The roles that you mention “HR Manager and Accounting Manager” are not native roles in WordPress, they may have been customized for your organization.

Your existing roles can be edited, or a new role can be added. The capability to be added to a role will be the “edit_users” permission, and this can be done with a plugin named “User Role Editor”. Adding the “edit_users” permission to any role, along with WP admin dashboard access, will allow a supervisor to see all the users from the plugin’s admin page.

Alternatively, any supervisor can see their employees timesheet without the “edit_users” permission, they just won’t be able to list all their employees from the admin page. The link sent to the supervisor when a timecard is submitted will allow the supervisor (with or without edit_user permissions) to view and approve the timecard.