30knees

I found out today that when a customer visits "Home> My account>My vouchers", the customer can see ALL cart rules ever created that match the customer group. This does not seem right to me because it prevents any selective distribution of vouchers. For example, if I want a voucher to be valid for all customer groups, but I want to distribute it only to people on Facebook, this feature/bug prevents that. Not only will the intended recipients on Facebook see the voucher when I post it there on my Facebook page, any customer who visits their account and clicks on "My vouchers" will see it, regardless of whether they use Facebook or not. Is this a bug or a feature? If it is a feature, is there any way to prevent all vouchers from being shown in this way?

@alwayspaws But please note that it doesn't properly delete the orders (and I think also not the stock - did you check whether it replenishes the stock?). See this post: https://forum.thirtybees.com/topic/793/suggestion-delete-orders-directly-in-the-backend

I am revisiting this question. I got some spam orders from people who apparently just wanted to test the order process and entered nonsense names and addresses. What is the best way to delete such orders AND restock the products? This is such a basic functionality. I do not understand how it is not in the system.

This is an interesting discussion. I think it's difficult for the people behind thirty bees to please everyone. I know I've been annoyed a couple of times in discussions about the project and features / changes I think are important, but I'm not the driver behind the project and I try not to get dissuaded from contributing. I think the most important thing to keep the community and contribution spirit alive is to explain carefully why one rejects a contribution, a suggestion, etc. No serious effort to improve the project should be rejected without an explanation. Also, I don't think it is good when people like @eleazar leave the project because of some dispute and where, at least to an outsider, it doesn't seem like there's much of an effort to keep him or try to rectify a misunderstanding. Finally, while I think Patreon is a brilliant idea, I would rather spend my money on developing modules I think are useful, or even core changes, and have them become an open source part of the project. I hope that thirty bees is open to this approach.

That would be a great module. Good find!

Yes - I am a strong believer in adapting data protection law so that usability does not suffer. It's definitely possible. Great post, @Traumflug.

@lesley said in New General Data Protection Regulation 2018-05-25: Its not that I am skeptical, there is a stark difference in my mind in data protection and data deletion. We are very security minded here and try to make it impossible to leak data, so I feel like the protection part is handled. Not for lawyers. "Data protection" is a poor term that has come to represent how data is is handled. One part of it is data security. The principles of data protection are found in Article 5 GDPR and include "data minimisation" (collect only the data you need) and "storage limitation" (keep it only as long as necessary). The security bit is called "integrity and confidentiality". See we are back to it being a German issue again. No, no, and no. :-) It's a European law. ALL EU/EEA authorities audit data retention/storage limitation. Swedes, Finns, Norwegians, Dutch, Austrians. This is the comparison of the OJ Simpson case to the shop lifting one. Germans are the most vocal merchants. It doesn't mean this is not an issue elsewhere. Again, I am happy to reach out to non-German authorities for you. I would like to get some other input on this, because the requirements you stated, I said how we could meet them. Do you mean from me or from a third party? If from me, I am happy to have a call and go through in detail and evaluate different options. We talked about this by email already. Ping me whenever. If from a third party, gladly.

The articles were about data protection authorities in general. Not specifically about deleting data. Authorities conduct regular data protection audits of companies, both on a random and a targeted basis (eg due to customer complaints). Mostly, the outcome of these audits are not made public. That one is unaware of them does not mean they aren't there. It's like with criminal cases: The OJ Simpson case hit the headlines worldwide, the small-time shop lifting case doesn't even make it into the news. You seem to be very skeptical. I'll tell you what, @lesley. I'll contact the country data protection authorities of your choice and give them the questions you want to know. About OS commerce derivatives: There are a lot of them still active. And regardless: dead or not, they can deal with the all of the above. Maybe their architecture is smart, after all. Shouldn't systems empower the owners and not restrict them? I think we can all agree on that. Take a look at Shopware, which has come to dominate the German market. It's also fully compliant. I can't comment on the other systems - you're the expert. I find it hard to imagine that most can't deal with the very simple requirements I stated.

@lesley said in New General Data Protection Regulation 2018-05-25: I think I might try a redirect. I have used most platforms under the sun, can you name one that will actually comply with those laws? I know for a fact that Shopify doesnt. I think most os commerce derivatives should be able to comply, such as xt commerce or modified commerce.

@mdekker said in New General Data Protection Regulation 2018-05-25: Can you name a few examples? Most small merchant cases don't get reported. My statements come from professionals in this area working in these countries. But: France: https://www.cnil.fr/en/facebook-sanctioned-several-breaches-french-data-protection-act Italy: https://www.insideprivacy.com/international/european-union/italian-dpa-issues-record-data-privacy-fine/ Netherlands and France: https://www.theverge.com/2017/5/17/15651740/facebook-privacy-violation-france-netherlands-fine and https://www.lexology.com/library/detail.aspx?g=ad2e6ff6-3f68-4b74-bddf-ddffce701466 etc.

@lesley said in New General Data Protection Regulation 2018-05-25: One thing I have noticed, you can even notice it with this thread, is the regulations are only problems for the Germans. These are German changes, not EU changes. 70% of thirty bees shops are EU companies, the Germans are the only people that seem to be having these issues. How do you come to this opinion? :-) The UK's ICO is one of the most active in this area, the Dutch are super strict, same as the Spanish and French. Poland and Italy are crazy strict, too, and have in many areas of data protection requirements that go beyond other member states. Please don't confuse a vocal merchant community and an active media for how things are behind the scenes.

@lesley said in New General Data Protection Regulation 2018-05-25: I think one thing that people in the EU miss when talking about these laws is they are front facing laws. Disabling an account should bring you in compliance. Data does not have to be deleted. Here is a great scenario. Would it be possible for me to commit a bunch of fraud and before I got caught send my bank a right to be forgotten letter asking them to delete my data? Every crook would do this. Another example is what if I buy a product with a lifetime warranty? Do I give up my warranty when I ask to be deleted? How far do you actually take this information? When I want to be deleted I want to be removed from your old paper records. I want to be removed from your tax filings, I want my name no longer associated with a purchase in your shipping carriers records. I don't want to show the payment in your bank account from 2 years ago. I want you to physically forget you ever talked to me. Deleting the data is not realistic and is actually illegal in the US under a lot of circumstances. That is not how the law works. It's not about deleting all types of data. This is a common misunderstanding. It's about deleting data that is a) no longer subject to a legal obligation to be kept or b) no longer required for the purposes for which it was originally collected. Those are the cases I gave above. Simply disabling an account MAY bring you in compliance, but it MAY NOT in other cases. It depends on the data processing. Taking your fraud case: No, you could not make your bank to do this. There are a bunch of other requirements that oblige the bank to keep the law. Taking the lifetime warranty: No, you do not. You may keep a record of the warranty yourself. The other cases you all mention are mostly not subject to a random deletion request by the customer. All of these cases are subject to certain retention periods. About deleting data not being legal in the US in certain circumstances: It's the same in the EU. I think we need to decide: Should tb be guided mainly by a US understanding or would you like to also let the EU influence its development? When I posted on my old EU shop platform's forum about tb, a lot of the (annoying) replies were: Ah, it's a US company, they'll not really have our (EU) interests in sight. I hope that was wrong. Also, if we take a look at Shopify from Canada, which is also very popular in the US: They actively recruit privacy engineers and they also have a sizeable privacy department. That isn't only because of the EU, but because of legislation around the world, including the US. Finally, the laws are not only front facing. The regulators do actually audit companies for their data retention plans and data clean up processes. They check what data is collected for which reason. The regulators are becoming increasingly tech savvy and also inspect eg data flows from the merchant's shop to third parties such as payment providers.

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