datakick

Can we get some update on future plans? There are bits of information scattered all over the forum, but it's very incoherent. I know there will be work on new updater (although I see this feature as an unnecessary overkill), and I guess there's work in progress on gdpr module. Anything else? What features, if any, are planned for upcoming release 1.0.5? Also, what features are planned for next major 1.1.x version, and what is the timeframe? For example, @lesley said that there are plans for integrating some page builder into the core. I also have plan to build a paid module with similar functionality, and at the moment I'm not sure whether it makes sense or not...

The link you have provided describes requirements for content published on Europa website. I'm sure these requirements meet all the European laws (cookie law, gdpr law, etc...). But that does not mean these requirements are the law. It's basically just a 'company policy', a policy that is more tough than necessary. When we are talking about GDPR, we should stick to the text of GDPR law. So once again, where in the actual law is written that "Persistent cookies are considered to be personal data"? It's really a rhetorical question. We clearly don't see eye to eye on this matter, so it's indeed moot to continue this conversation. I'm very frightened, though. I really hope you guys don't strip all the important features from the tb platform, and render it unusable for merchants

@traumflug said in PGRD Compliancy Module: It’s written here: http://ec.europa.eu/ipg/basics/legal/cookies/indexen.htm#section2 That link is not GDPR law. I don't care about that. The text of GDPR - Regulation (EU) 2016/679 is here. Now, where in this text is any mention about cookie persistence, etc?

@lesley I agree with you. Basically, any collected information that can be used to identify natural person is subject to GDPR. In this case I'm not sure -- machine footprint can (to some extent) identify anonymous visitor, but is it the same as identifying natural person? I agree that we will need to wait for a court decision. And it will be really interesting, as it will impact all analytics solutions that exists. But that doesn't change the fact that cookie lifespan/persistence is not a factor in GDPR. I just wanted to point it out, so you guys don't implement something that's not really necessary into the official GDPR module. There's no need to change tb cookie to session, as it doesn't change anything. It definitely won't make thirtybees more GDPR compliant.

@traumflug said in PGRD Compliancy Module: Persistent cookies are considered to be personal data for their sheer existence. It doesn’t matter what’s inside. This is nonsense. Show me where, in the GDPR text, is this written. As a specific example: when I create persistent cookie that contains theme=light(and I obfuscate/omit IP addresses from nginx/apache logs), how can this be considered personal information? Show me how this cookie could be used to identify natural person. If you can't, it's not subject to GDPR, even though it's persistent cookie. Another example: when I create session cookie that contains [email protected], then every request to my server will contain this cookie. If I collect/process this information on server side in any way, then I've breached GDPR law. It doesn't matter at all that this information was stored in session cookie. Everyone, please stop with this session/persistent cookies nonsense. Although it's important in cookie law context, it doesn't matter for GDPR. For GDPR, only cookie content is important. If cookie can be used to identify natural person, either directly or indirectly, it's subject to this law. Otherwise it's not.

Another version is out List widget redesign In this version I've redesigned review list widget, so it can be used anywhere in your store. This is an important step towards another interesting features, such as review carousel or custom review lists New displayRevwsReviewList hook You can now use hook named displayRevwsReviewList anywhere in your smarty templates. This hook will render review list. By default, all reviews are displayed. You can customize it using following hook parameters: displayReply - display shop replies or not. Allowed values: true | false. Default true displayCriteria - controls how to display criteria breakdown. Allowed values: inline | side | false. Default value is the one set up in your settings reviewStyle - controls review style. Allowed values: item | item-with-product. Default value item order - how to order reviews in list. Allowed values: date | usefulness | author | product | title | content | grade | id. Default is date orderDir - order in descending or ascending - Allowed values: desc | asc. Default value desc pageSize - how many reviews should be displayed on one page. Default 5 reviews allowPaging - controls if paging is allowed or not. Default value true product - display reviews for specific product only customer - display reviews submitted by specific customer guest - display reviews submitted by specific anonymous visitor category - display reviews for products from with specific category categoryTree - display reviews for products from with specific category and all its subcategories manufacturer - display reviews for products from specific manufacturer Example usage: to display 3 newest reviews on your homepage, simply enter this somewhere into your index.tpl file in your theme. You can see the result on my demo account - I've incorporated two review lists to my homepage. One displaying recent reviews, and another featuring best reviews. {hook h='displayRevwsReviewList' allowPaging=false order='date' pageSize=3}

In backoffice? Copy code between lines 29..57 from file <admin>/themes/default/template/helpers/list/list_footer.tplsomewhere to file <admin>/themes/default/template/helpers/list/list_header.tpl. For example paste it to line #245, just after {block name="preTable"}{/block}

@toplakd said in PGRD Compliancy Module: Session cookie with 0 value expires when browser closes and does not need any consent or blocking Yes, but it will also log out your customers. Your anonymous visitors won't be able to access their cart once they close the browser,... It's too drastic. Why do it, if it's not necessary?

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