datakick

@toplakd said in PGRD Compliancy Module: We will have to get used to use true session cookes, as otherwise all pages on first visits will be crippled with popups. Remember that GDPR does not restrict use of cookies. It just says that when cookie can identify an individual (physical person), it is considered personal data. All other cookies are not subject to this law (but other existing cookie laws still applies, though) The big question is whether thirtybees core cookie can identify individual or not cookie for guest / anonymous visitor When user first visits your site, the cookie contains these information: [date_add] => 2018-05-24 10:59:37 [id_lang] => 1 [id_currency] => 1 [viewed] => 1 [id_guest] => 91 [id_connections] => 300 [last_visited_category] => 6 [checksum] => 3940892666 What is problematic is id_connections, because it points to the tb_connections table, which stores visitor's IP address. IP address is personal information, so we need consent for this cookie. The big problem is that we have already collected this personal information. We have already violated the GDPR before the visitor even saw our site, and before we even issued the cookie. So, the first thing you'll wanna do is to disable module Data mining for statistics -- that will fix this problem. We will lose statistics, though. While we are talking about this, you'll also need to modify your apache/nginx logging settings, and omit/obfuscate IP addresses from your access/error logs, as this is also a GDPR violation. So, once we have disable logging IP address into tb_connections table, there's nothing in the core cookie that can be used to identify physical person. Such cookie is not subject to GDPR, and we can safely continue to use it. #### cookie for logged in customer When customer sign in, cookie now obviously contains personal information. So, in order to use this cookie, we need consent. This is easy - just ask for it during customer registration. Single checkbox with link to our privacy policy. There's no need for dedicated consent for the cookie itself. So, what's the reason to convert this to session cookie?

Ahh, I see where the problem is - this has nothing to do with php version, there's hardcoded check in /controllers/admin/AdminTranslationsController.php, line ~988

@toplakd what php version do you have? As of PHP 5.4 $_LANGMAIL = []; should be perfectly valid expression, so it seems you have older version. Note that Thirtybees will not run correctly on PHP 5.3 or lower

... one more thing - my module does not support csv import yet, only xml :)

Not directly, but it will be supported soon. Meanwhile, I can offer this workaround: 0) Preparation step - create custom field named Imported Quantity for products (or combination) Then: 1) run Mass Update that will reset Imported Quantity field to zero for every product 2) run Import that will import data into this new custom field Imported Quantity, instead of build-in quantity field 3) run Mass Update that will copy data from Imported Quantity to standard quantity field If you run these 3 steps in sequence you'll get wanted results. Unfortunately, datakick module does not support task sequencing at the moment. But you schedule these task to run at specific times. For example, you can schedule first mass update to run at 10:00, import at 10:05, and copy data task at 10:10 (or maybe later, depending on how long does it take to import data)

@nickon I'm afraid that can't be done programatically / automatically. Ultimately it's up to merchants to decide if the module complies with the laws.

@lesley, you are right, there are many parts of the code that's not released under open source license. They are licensed unter this --- which is not a license at all. But I guess that doesn't mean I can use it anyway.... so sorry folks, no ported GDPR module :)

@lesley thanks, I'll go over the code again

For those of you who would like to test/use official prestashop gdpr module, I've ported their free ps17 version to ps16 / thirtybees (credits for the idea goes to @toplakd). ...download link was removed, because original ps17 module is not entirely open-sourced...

@violinparts changing hook (displayHomeTab) position works fine for me

thanks for confirmation. I've created a pull request, so the fix should be part of the next module version

There is bug indeed. To fix it, modify file /modules/blocknewproducts/blocknewproducts.php and change line ~308 from foreach ($caches as $template => $cacheId) { Tools::clearCache(Context::getContext()->smarty, $template, $cacheId); } to foreach ($caches as $template => $cacheId) { Tools::clearCache(Context::getContext()->smarty, $this->getTemplatePath($template), $cacheId); }

Today I've released new version 1.0.15 - this one brings in some GDPR nonsense. You can newly choose to display consent checkbox on review submission form, if you think it's necessary. It's probably not, but better play it safe than be sorry. It also integrates with official prestashop GDPR complience module. That's not probably very interesting for you thirtybeerers. But in case you are running ps17 somewhere, or if you have bought ps16 version, you can use it to export and delete user data.

Here are official guidelines from ps how to make community modules GDPR compliant @SnowyCat / @lesley - will thirtybees GDPR module be compatible with these hooks? It would be very unfortunate if it wasn't, as all ps16 modules who implements these guidelines couldn't be used on thirtybees

All right. I'll implement csv data export and data deletion into my modules. Once you guys have GDPR module ready I'll integrate these features with your hook(s)

@lesley thanks. I hoped that the consent won't be necessary. So I guess there will have to be two new hooks that core (or GDPR module) will trigger. One hook for data deletion, and one for export. These hooks should probably receive customer id and customer email as input parameters, so modules could find the data accordingly. The deletion functionality is quite straightforward, export is more tricky. Will it be sufficient if module returned associated data as one big string blob?

I know next to nothing about the upcoming GDPR sh*t, so I wanted to ask more knowledgable people on this forum if there's anything I need to change in my modules to make them GDPR compliant. I have two modules that I believe could be affected - revws module that collects product reviews, and price alert that notifies your customer when prices drops below some threshold. Both these modules collect personal information, specifically email addresses. So, do I need to add some sort of consent on form, or will this be covered by some generic site-wide consent? Also, do I need to implement some hook to delete user's data, say hookEuropeanBureaucracy? Is there anything else I need to worry about? I would really like to have some sort of GDPR compliant badge on my modules :)

Because perk is considered sale of digital service, every EU-based patreon will be charged VAT according to his country. That shouldn't be a problem for businesses, as most merchants are VAT payer, so they can deduct this charge back. This only negatively impacts patreons without VAT number.

I've released new version 1.0.14 -- added support for Multiple languages. You can now choose to display only reviews written in visitor's language. This settings is recommended for any shop using multiple languages feature: it will reduce the noise on your product page, displaying only information relevant to each visitor it will have SEO benefits - no duplicate content between different language versions Of course, you can disable this feature and keep displaying all reviews regardless of language. This can be useful in case you haven't collected many reviews yet.

@rubben1985 said in Landing pages: I already said once that CMS and landing pages is the biggest hole That is very interesting information for us, developers. Although I'm not sure if it's really so requested feature - when I did the poll about what free module to develop, nobody suggested this functionality. ...which is a shame, I'd love to work on something like this. That's exactly in my wheelhouse...

Another minor release 1.0.13: ability to trigger review dialog using url parameter named postreview, ie: https://www.domain.com/en/home/my-awesome-product/?post_review. Same parameter is used by @SLiCK303 's send review request module. This change shouldn't affect integration with this module at all added support to choose layout (left and right columns) for MyReviews section check module version now display release notes

It seems like the problem is that the module prefixed namespace of stripe library with ThirtyBeesStripe, but the prefixer program didn't replace references inside Util.php - it tries to use unprefixed class Stripe\Customer instead of ThirtyBeesStripe\Stripe\Customer You can try to modify file modules/stripe/vendor/stripe/stripe-php/lib/Util/Util.php, edit function convertToStripeObject, and add this ThirtyBeesStripe prefix to all objects in $types array, and also on line 117. But obviously this needs to be fixed on different level - paging @mdekker

Error code won't help us, it's encrypted using your server's key. You'll need to paste it to Advanced Parameters > Logs > Decrypt an exception message to get plain version. Then you can decide if it's safe to post it here

@30knees said in CSV Import killer app features list: Take a look at the @datakick module. It's very capable! Thanks for the shout-out! Unfortunately my module can import only XML files at the moment, CSV support will come soon.

This is indeed nice feature, but I'm afraid the implementation won't be trivial. First of all, quantity on hand for packs can't be just some virtual number calculated in php. There are numerous places in core (and in hundreds of modules) that expects quantity information to be stored in stock_available database table. It's not possible to fix them all. So, to implement this, we would need some synchronization mechanism that would keep data in stock_available table in sync - whenever quantity of child item is modified, we'd need to update pack quantity as well. I'm afraid it will be very hard to keep these in sync, even if we used database triggers.