30knees

@daokakao So basically setting up tb to not use something like Elastic email but go through the email provider of your choice?

I don't know, but you could try translating here and then importing from there: https://crowdin.com/project/thirty-bees/et

I agree - some customers have told me information is missing in their emails, eg bank details. It would be great to get the exact same email the customer gets, even if it's just looking at the email under Advanced Parameters>E-mail.

Hi, Is Anonymize IP setting activated in the thirty bees module? https://developers.google.com/analytics/devguides/collection/analyticsjs/field-reference#anonymizeIp I think a little option box on/off would be a nice feature.

@dynambee Take a look here: https://forum.thirtybees.com/topic/1078/how-to-mark-a-thread-as-solved I agree it is a bug.

What do you mean exactly?

Hi, I'd like to import customer reviews from my old shop into the new shop. I didn't import the old customer accounts, so I can't map the reviews to existing customer IDs. What would be the best way to import the customer reviews? Can I assign each review to a new unique customer ID without any associated information such as email address, physical address, etc., but with their name/initials? If so, how do I do this without messing up the customer ID table that already exists in the new shop? And how can I mark the new unique customer IDs as guest accounts? Thanks!

I would argue that if the prohibited transaction was done via the Envato platform, it should be on Envato to not have either any developers or end-customers who are located in restricted countries. Any user of the platform should trust in Envato doing their duty and that all users are vetted and can transact with each other.

@wakabayashi Bug or is there something I need to consider when activating ASM regarding existing stock? I activated ASM. I set a default warehouse. I went to a product and activated ASM there. When I did that the product's stock quantities suddenly changed from 47, 2, 7 (different attributes) to -21, 0, 0, if I remember correctly.

@traumflug Thank you! I'll add the code right away. The customer still hasn't replied.

Cool! I'll mark as solved (and need to post for that - I can't select dekker's post)

Nope. I only have enabled: Website Payments Standard

Hi, I have a PayPal order that is marked as paid in the shop but online in my PayPal account it's marked as pending. Is there a setting somewhere that I overlooked or might this be a bug?

Waiting for the reply. :-) If it's not the plus, I'm wondering whether she used the letter oh instead of a zero. Thanks for the explanation of the *!

A customer wrote today saying they couldn't order because their phone number was being rejected as invalid. I followed the instruction here https://www.prestashop.com/forums/topic/393876-how-disable-phone-number-format-check/ and did this: Find in classes/Validate.php public static function isPhoneNumber($number) { return preg_match('/^[+0-9. ()-]*$/', $number); } and change to: public static function isPhoneNumber($number) { return true; } I'm wondering what the customer might have entered that gave the error. Do I read the original code properly that it demands a plus? If so, it might be a good idea to change that. I'm sure this affects lots of customers.

This is smart. Did you find a fix in the meantime?

@jamesblond008 Awesome! So I can only mark my own posts as the correct one.

I don't think I have that. Neither primary post nor any other post. See screenshots. I used to have it, but something changed. I thought it was the forum software. But maybe it's my account?

I don't think so. The state was filled out initially when "state" was active. And it didn't work when state was active and the state was still there from the first attempt. I had to re-save the address after turning off "state" to get the state dropped from the address.

I solved the problem, and I think this is a bug. "State required" was activated. When I turned it off, I tried checking out, but that didn't work. Then I thought of going back into the address and saving the address again without the "state" field. That worked. But why would having the state activated cause this problem?

The product can allow all carriers and the country is enabled. If I move the country to another carrier I get the same message.

The database entries under tb_country for two countries that belong to the same zone with the same carrier, where one works (Poland) and the other doesn't (Italy) are also the same. Is there any other place in the database I can check?

The error is back, unfortunately, and we are no longer using OPC. I have the country, a zone, and a carrier. Any ideas for the trouble shooting?

OK, that's it. :) I made the mistake of assuming all customers under customers are registered - this is different behaviour than my old shop. The customer is twice as a guest and once as a registered customer. So no bug after all.

OK, I'll take a look at it!