30knees

It looks like it was reported already here: https://forum.thirtybees.com/topic/862/bank-wire-resend-email-does-not-display-bank-information/

Was this ever fixed? It's still here: https://forum.thirtybees.com/topic/1107/bank-wire-resend-awaiting-payment-email-bug/2

Thanks! I'm not using PHP 7, though, so it must be something else. I've also read instructions on how to translate, eg https://www.prestashop.com/forums/topic/460777-tipp-wie-finde-ich-%C3%BCbersetzungen-die-ich-%C3%A4ndern-m%C3%B6chte-gilt-nicht-f%C3%BCr-prestashop-17/ but I did that.

Thanks, guys. I cleaned up the database. @traumflug That's the problem. The orders were untouched by me. The only commonality I see is that they were processed using the beta PayPal module.

Hi, I am having some weird behaviour. Some orders are displaying in tbcart idcarriers that don't exist. This does not affect tb_orders. I have these carriers: In the database under tb_carriers I have all these entries: Question 1: Can I delete the ones that don't exist anymore? But in tbcart some orders have three figure idcarriers: Because the idcarriers for idcarts 307, 317, 319 don't exist, I'm getting problems where some action relies on the idcarriers entry in tbcarts. Question 2: Does anyone have an idea where these idcarriers could be coming from/getting into tbcart (and not into tb_orders)? Of the three carts, one was non-ordered/abandoned and two were PayPal orders using @mdekker new PayPal module (no idea whether coincidence or not - other PayPal orders have been processing fine).

Hi guys, I cleared the cache multiple times and also waited 24h before posting here to be sure it's not a cache issue. @moy2010 That's the thing. I don't understand the structure of the language modules. I think I only edited the translation files - when I go Localization>Translations>Installed Modules>Core>English I see all the "original" entries of the developer and my new ones are translations. But I don't know where to look for the original entries...if I go through the module, it looks like they're scattered here and there in different files. But, to answer your question: In Localization>Translations>Installed Modules>Core>English the translated fields are all filled with my edits in en.php, not with the default ones. In Localization>Translations>Installed Modules>Core>German the translated fields are only partially filled with my edits in en.php ... and not at all from de.php and not from the default ones, either.

What about a link to the store where they can set their own password?

Hi, I have a module with horrible translations. I had already installed it. So I went to the module's translations folder and edited the files there, eg en for English, de for German. However, while this worked for English, it did not for German. I go into Localization>Translations>Installed Modules>Core>German and the German translation fields are partly filled with the core English translations. What might the problem be?

Super, I'll try and report! It's not a lot of reviews. Maybe 60 or so.

The product IDs don't match, but I have them all mapped out. For example, I know that 32 old = 64 new.

Panda theme uses the same email templates. I agree that the standard ones are a bit difficult. I haven't gotten around to editing them yet, but it's on my to do list.

Hi all! Thank you so much for helping out! :) The old system has the following table entries for reviews: reviewsid productsid customersid customersname reviewsrating dateadded reviews_text [As an aside: One nice thing about that is that one could edit customersname independently of customersid ... as I understand tb, the displayed customersname (or the equivalent) for reviews is pulled from the name connected to the customersid, so it's hard for customers to submit a review using a nickname.]

No ideas? :(

It's not just Germany :) They only have the most publicity. The Norwegian authorities had this on their radar in 2012 (?). But super that it'll go onto the roadmap. Thanks!

It's best practice in the EU in order to be compliant with data protection law. It'll only get stricter with the GDPR. Would you be able to implement a tickbox to activate/deactivate the function? Here's some information I quickly found on the legal status: https://www.iubenda.com/blog/privacy-policy-google-analytics-germany/

I have the same problem. It's not just when you resend the email, but when you create the order in the backend and send out the initial email from the backend.

I entered carrier percentage values of 120 in the dashboard statistics field for carrier percentage values: AVERAGE SHIPPING FEES PER SHIPPING METHOD. I got an invalid error message. I think it always expects a value of <100; at least that's what it looks like from the example instructions: Method: Indicate the percentage of your carrier margin. For example, if you charge $10 of shipping fees to your customer for each shipment, but you really pay $4 to this carrier, then you should indicate "40" in the percentage field.

@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.