kasparsmime

Hi, I have the same issue.
It is not a conflict with a theme or other plugins in my case.

@ktseiko have you already reported this issue on Git or found a solution?

Hi,
Yes, I can confirm all that. Double checked and none of the new custom checkout fields showed up in the PDF invoice.
Also had an issue that if I wanted to update address in My account – conditional fields that were set as Required when displayed in checkout, they were required in in My Account by default, but not visible.
Anyhow, I have since replaced your plugin with a different one as it was a matter of urgency to sort it out.

@codewoogeek
Thank you so much for a swift action. Update installed and will test over the next few days!
Well done!
Regards,
Kas

@codewoogeeksupport
I have a concern though about the fact that system sent out messages to subscribers without stock change and registering the sending actions in log files. Any idea how this could happen? We want to avoid that in the future as it confuses the end user and we get questions asked from them.
Thanks

Hi

@omnisite thanks for your involvement and advice.

@codewoogeeksupport I did tests on staging environment without uninstalling plugins first. My finding are that all messages were sent when receiving stocks via the third party plugin. But only one product ID is processed at a time, meaning, if there are more than one product returning in stock, the second one is processed in the consecutive cron job running (after 5min).
Issues I had on the production environment I still need to observe as and when stocks come in.

Hi there.
Unfortunately on top of the issue of plugin having inconsistency with back in stock message sending, last week we had a occasion when a many messages were sent out to subscribers even though products did not return in stock. Also logs do not contain any messages sent about back in stock products. Only couple new subscribers.
Do you have a list of incompatible plugins that we could check if we use any of them? Would be great to solve this issue once and for all.
Thanks.

Thanks for a swift response.
Much appreciated.

Hi, do you have any timeline when this bug could be fixed by?
Thanks

Thanks for directions.
I found that latest emails were triggered by background process – so automatically. But only for one of the products that returned in stock, and not for the other one.
Other one had email sent out today manually by admin- which I see in logs as per your description.

In pending scheduled actions I see 2 of the cwg_schedule_third_party_support hooks registered.

Any ideas where is the inconsistency coming form?
Thanks.

Hi,
Today we had couple products returning in stock via a 3rd party plugin. Your plugin sent out messages for one of the products – presumably automatically, as we have more people working in the admin, we don’t know 100%. But not for the other product.
Is it possible to check if these messages that were sent out used automatic or manual sending method?
Thanks

Hi there, thanks for a swift response!

Status all looks fine, Cron is Active and Test email arrives. Also have reactivated plugin as you suggested. Will wait to see it that has sorted the process.
See screenshot here: https://prnt.sc/1w3n8q5

Thanks

Great, thank you. It works!:)

Hi, thanks for getting back.
My main issue is that if a user has put a Frequently Bought Together deal in the cart, I don’t want to give a chance to them to get even bigger discount by adding a coupon (if they have one). And at the moment coupons are accepted and adds more discount to these deals.
When you said “In this plugin, you can’t apply coupons for frequently bought together deals” – did you mean something else?

Amazing work Oleg, thank you so much!
I tested it and it works! Much appreciated!

Hi Oleg,
I actually had this error today after updating to v.2.1.1
Error:
(GSWOO\Services\SheetInterplayService::get_sheet_csv) { “error”: { “code”: 400, “message”: “Unable to parse range: File name”, “errors”: [ { “message”: “Unable to parse range: File name”, “domain”: “global”, “reason”: “badRequest” } ], “status”: “INVALID_ARGUMENT” } }

It went back to normal when I reverted it back to 2.0.3.
What shall I do to make the 2.1.1. work?
Thanks.