30knees

@lesley said in New General Data Protection Regulation 2018-05-25: Sure. Deleting orders. This is against the simple premise of ecommerce. When an order is deleted, stock should be returned. Deleting orders will put stock in your shop that is not actually there. Guest customer data is goo historic data. It has no named tied to it, so no one can claim ownership of it. Keeping guest customers should not be an issue. When they are deleted, it will break orders. This is a major rewrite, nothing that can be put into a 1.0.x version. Anonymous / nicknames for reviews do not build trust. That is why most review systems use the name tied to the account, not an alias. This also could be a breaking change, because on some level internally the review is going to be tied to a name, or it will not be a verified review. Thanks for the details. I think all of these points can be addressed/fixed with a proper discussion (we'd need to phone, quicker). But: When you delete an order, there should be a check box: Restock (y/n)? You might want to do this because there are spam orders/test orders/whatever. Give the freedom to the merchant to decide. I have guest data of customers who never placed an order with an email address. I can follow up on the customer if I want to, but I should also have eg a 14 day auto delete possibility. Again, enable the merchant. Agree with customers who placed an order. But I have guest customers (different customer ids, but same email) who "signed up" multiple times but who only who placed an order for one of these. Let's only keep the customer id where there's an order. We can have verified reviews and non-verified reviews. Again, let the merchant decide. Don't force something on the merchant. Different cultures, different approaches to ratings, etc. You can have only the initials of a customer, for example. The MAJORITY of my customers only gave a review when we enabled (in my old system) reviews with initials. Again: Let the merchant decide.

Would you mind providing some substance to your opinion on: Over complicating Not possible in some levels in thirty bees or most other platforms. (My last platform was able to do everything.)

The GDPR is not a plan to over-regulate and make it hard for small businesses. It actually makes things much more difficult for larger businesses with complex processing activities. It's quite straightforward for shops like ours. Though I do agree that it's not the most brilliant piece of legislation out there. It definitely has its flaws. Some things that should be implemented off the top of my head and without going into the specifics: Google Analytics AnonymizeIP Delete orders Edit orders Not keep guest customers indefinitely Not keep indefinitely guest visits who didn't finalise their oder but where we captured their email address Allow nicknames/anonymous name for reviews

There is no possibility, unfortunately, as far as I am aware. This is also something that should be fixed for this: https://forum.thirtybees.com/topic/1135/new-general-data-protection-regulation-2018-05-25

Also, I'm not using PayPal Express. In addition, though, the update doesn't install all files on my server: https://forum.thirtybees.com/topic/1095/paypal-6-0-0-beta-1-the-final-push-for-victory/52

Nothing in particular, I'm afraid. They all had the same basic functionality. This one did have a decent payout export feature, something I wasn't able to find/test elsewhere.

That's odd, I don't have the file. I just uploaded the new beta2, never touched any files.

It's a totally normal address and the same as many others I've shipped to, nothing wrong with it. How can I try to figure out why the system might have marked it as not shippable?

Yes, so many options. I played around with the backend of them all and even though the language of the one I posted wasn't the best, it felt the most functional and thought out to me.

I'm looking at this one now: https://addons.prestashop.com/en/sea-paid-advertising-affiliation-platforms/26226-full-affiliates-pro.html Has anybody used it?

Also from the module author: PS: if you need to mass-assign / generate reference ids for your products, then there is already a prepared mass update for this in the store — it will update all products with missing reference id — assign a new one using formula REF-{productId} You could also schedule this mass update to run on regular basis to ensure that there will never be product without reference id. It's great support!

Here's the answer from @datakick (Thank you!) This is the process in short: install GMC feed template into datakick install GMC feed template from the store - you can open store in datakick using menu in upper right corner there are two feed versions you can choose from - products only or combinations. If you use product combinations in your shop, use the later, otherwise use the first one Choose a way to generate an XML file from template you have two options to generate XML file endpoint - you can create a special URL. Anytime this url is opened, fresh XML file is generated and send to the requester. This is the easiest method, that ensures that data are always fresh. However, it can be used only if the feed generation time is low (less then few seconds). If you have many products in you store, this task can take much longer, even a few minutes. Then you have to choose the second option scheduled task - you can create a scheduled task, that will periodically generate the xml file and stores it on your server, or upload it to the ftp server. For this to work, you first need to setup CRON task - cron is an external application that opens some url on your server periodically, so we can use this event to execute our processes. you can also generate the XML file directly from datakick module. Just open the template, an in upper right corner click on ‘more’ button. Then you can download file to your computer (the same mechanism as visiting endpoint, or generate xml file on your server - simulates scheduled task). upload file to Google Merchant Center That’s basically it. After you upload your file for the first time, google will process it and it may return bunch of errors. The most common issue is that product feed does not contain ID of your products, or IDs are duplicate. This problem is caused by the fact that datakick uses product reference code as ID when sending data to google. Prestashop doesn’t require this field to be set, or to be unique, and that may cause the issue. If you have this problem, you can either fix your data - find product with missing / duplicate reference and fix these, or change the template and use product real ID as GMC id. The second solution will work just find, however it may cause you problems later - for example, if you delete all you products from prestashop and re-import them, they will get assigned different IDs, and google will not be happy with that.

Now I got an order with tbcart's idcarrier 0 (doesn't exist). In tborders the idcarrier is 29 (correct).

Did you update any modules?

Yeah, it looks like the XML format that the module provides via Google Merchant Combinations is faulty. Manually uploading a combination export gives the error: 1 ERROR: XML formatting error

Hi @datakick, we are testing your module and are struggling with setting it up for Google Merchant with Combinations. The problems we have are: The Combinations feed always fails. A regular Products feed works. Where in Google Merchant do we connect the endpoint URL? When I run the endpoint URL that is generated, it creates an XML file. When I enter that URL in Google, it says the URL is invalid because it would need a file ending. Thank you

@roband7 Thank you for not giving up and checking the code! I'm happy to test the beta module again once this has been fixed.

Hmm, I can't comment, but it sounds like an edge case to me and one that bloats the database. Is the decision then not to change the logic?

@lesley I strongly disagree, especially considering that it prevents modules from relying on an unchanging id_carrier. What historic purposes are there? All old prices can be kept in the old orders, for example.

@traumflug For example if one wants to adjust the shipping price, the weight ranges, etc. There is no reason why changing the shipping price should affect the carrier id.

p.s. Is there a query I can run to eg replace everywhere in the database, so tbcart and tborders and tborderdetail and anywhere else id_carrier 31 with 22?

I edited the price of two carriers and the id_carrier got changed and the old one deleted. Specifically: idcarrier 20 got replaced with idcarrier 29 idcarrier 21 got replaced with idcarrier 30 and then id_carrier 30 got replaced with 31 This messes up modules that rely on the id_carrier and assume it stays stable.

I checked the database to make sure there were no new three digit IDs before processing orders. There were two new ones, all PayPal orders. @mdekker Is there no way that the new beta PayPal module could be doing this?

@mdekker said in tb_cart having non-existing id_carriers: Don't delete old carriers. The software breaks if you do so. I did already, unfortunately. What exactly should I pay attention to to make sure nothing is broken?

@traumflug said in tb_cart having non-existing id_carriers: @mdekker, these three-digit carrier IDs are in table tb_cart. I take there's no actual carrier with such a number. Apparently a problem when a carrier gets selected/added to the cart. Correct, there is no carrier with those three digits.