datakick

@Manisch / @nickon - what is the percentage of customers who subscribe to newsletter / optin? I don't think it will be substantial. Does it make sense to somehow nudge customers to give consent specifically to send review request? I was thinking about some popup window that would appear after the customer completed the order (and only if he didn't opt-in for newsletter already). Here we could explain the benefits of providing review, ie say that he will receive discount coupon, and ask for the consent for sending review request by email. All without disrupting order process

Also, it occurred to me that my previous solution might be unnecessary complicated. We could just use different html markup. Instead of ``` Label 1 we could use Label 1 and <label> would be implicitly bounded with <input> without the need foridandfor``` attributes. The question is whether the CSS rules to display fancy checkboxes would still apply.

@daokakao said in Checkbox won't check - Art Free GDPR Module: @datakick the codepen example shows slightlyvdifferent behaviour: When i click second checkbox then 'v' mark appears/disappears in the first checkbox, this is obvious behaviour. In the real case the second checkbox does not reacts at all. It does (well, it did). This was the original behaviour - note that clicking on label in main form changes value inside popup: @manisch said in Checkbox won't check - Art Free GDPR Module: Sweet, thanks a lot! Seems to work :) Do you mind posting that also over at the Prestashop forum? First of all the solution could be useful over there, as well. Second I don't want to copy and paste it - you should get the credit. Glad I could help. Feel free to post the solution to ps forum. I don't really need the credit :)

@manisch there are many ways to do this. One possibility is 1) create static variable inside artfreegdpr module that counts how many checkboxes were generated during one request 2) edit hookCreateAccountForm and hookDisplayCustomerIdentityForm hooks - when hook is called, increase counter and pass its value to template 3) use this counter in template itself: Note that this module does not work with this checkbox in any way. Given consent is not stored anywhere, neither is verified on server side that it was actually checked... so it's not very gdpr compliant :)

@daokakao there's no javascript, it's all pure html + css solution. The label is styled differently based on associated input :checked status. See this codepen

@daokakao said in Checkbox won't check - Art Free GDPR Module: So, this div must be bound to some JS which should, in turn, change the value of hidden checkbox. Actually, this is all pure html+css solution, no javascript is necessary. It uses this HTML markup: ``` Label 1 thefor``` attribute on label binds the label with input with id gdpr - when you click on the label it actually toggles value of . And it works as expected. The problem is that there are two inputs with the same id: ``` Label 1 ... Label 2 ``` So, when you click on Label 2, the first will be toggled. You can see this behaviour on this codepen To fix this problem, we have to ensure that the two checkboxes have different IDs. That means edit /views/templates/hook/gdprCheckbox.tpl template, and replace hardcoded id with some variable that is passed from php hook. And ensure that hook generate unique ID

Ahh, I see where the problem is. Your theme has a feature to create account by clicking on person icon in upper right corner. In that case popup window will appear: This popup window contains this GDPR checkbox as well -- that means that your page contains two html elements with the same id. When you click on the label in your account creation form, you are actually switching state of the other input on the page (inside popup window) You gotta love html :)

I think that there may be some javascript that prevents default behaviour. It's hard to tell what js is causing this, because you are using CCC. If you disable CCC, I can have a look. From top of my head: the input id contains dash freegdpr-consent. This could be the problem. Although dash is perfectly valid character, it may confuse some javascript :) You could edit template views/templates/hook/gdprCheckbox.tpland replace all 3 occurances of this text for something different, for example gdpr. If that works... then it's a proof that you have some very buggy javascript on your site, and the same problem can appear elsewhere.

I forgot to clear cache after data erasure, I'll add this to the next version

@nickon let's agree to disagree :) I really think it's not necessary, but... have a look at my fork of this send review request module, where I've just submitted psgdpr support. Should do the trick... I haven't tested it thoroughly, so let me know if you found any bug. You will need to download git repository as zip, unpack it, and rename folder from sendreviewrequest-master to sendreviewrequest. I'll create a pull request, maybe @SLiCK_303 will integrate it to the upstream module

@nickon that can't be right. These are your data, not customer's. Example 1: Lets say I have an online shop where you can upload your photos, and I'll generate some PDF book from it. You can download it after you pay. Does GDPR give the customer the right to have this pdf book exported, just because it's related to him? No, that would be ridiculous. You can have your original photos back, if you wish. And you can ask me to delete everything about you (including the book). But I don't have to give you the book itself (unless you pay for it). Example 2: let's say that you calculate some sort of 'customer rating' and use it to give different prices to different customers. This 'rating' is based on order history, so it is obviously related to the customer. Has your customer the right to have this information exported? Or to even ask you to transfer it to your direct competitor? I don't think so. This is your information, generated by your sophisticated algorithm. Why should you tell your competitors how much you think this customer is worth? Your customer has the right to transfer his data to other controllers - he should get everything he provided. Be we don't need to give him anything else. We can, of course :)

@nickon I'm not sure if there's a need for this. Article 20 says that The data subject shall have the right to receive the personal data concerning him or her, which he or she has provided to a controller. Send Review Request does not store any data provided by user. It just logs information an email has been sent to customer with given ID.

That's true, models with namespaces won't work on ps16. In this case it's not important, as Send Review Request module does not use namespaces. @nickon - just edit file sendreviewrequest.php, and remove highlighted lines if (!defined('_TB_VERSION_')) { exit; } And it will work. This trick will not work on krona module, though, as it uses namespaces

@toplakd I've never said that the updater project should be scratched - I'm sure tb is somehow bound by contract with indiegogo to deliver the promised goods. I was asked why I think this is overkill, so I answered. If you disagree with me you are welcome to raise your counter argument

@lesley said in Thirtybees roadmap: Saving time is the only way we are going to get ahead with a small team. We have to look at our processes and refine them to cut the fat out. Two months ago if we decided to release a new version with an update we would be looking at 10-15 hours of work. Now we are looking at around 8. Once we get the updater finished we will be looking at 10 minutes worth of work. That is 9:50 that can be spent somewhere else. Of course I understand the benefits of updater, it's definitely a good thing to have. But I still think it's not needed at the moment. How much time will it take to build this? I assume at least 200 hours (and that's conservative estimate, considering all the features listed on the blog post). So you'll start saving time after 20 releases. If you will release every 2-3 weeks, you'll break even in a year. Is such high release rate good? As I already wrote before, I don't believe merchants will update their store so often, it's too risky. You don't have a QA team that would run tests and sign off the release. Also, with this high release rate, the submitted code won't have a chance to mature in the branch - your developers won't have so much time to discover new bugs before the release. It's much more likely that bugs will make it to end users. I personally think that 2-4 releases per year is more than enough. And with such release schedule it wouldn't make sense to invest so much effort and resources into an updater. That's why I think that the updater is an overkill. But this is just my opinion. As far as a rough roadmap, this is what we have discussed so far, but nothing is set in stone yet. 1.0.x - just bug fixes 1.1.x - modernize the front end, convert to bootstrap 4 and have a new theme 1.2.x - modernize the backend, convert to bootstrap 4 and have a new theme Thanks. Maybe it would be good if you guys selected some feature candidates, and let community decide/vote what should be implemented. Possibly let only patreons vote - that would be nice incentive for becoming one.

@nickon said in Thirtybees roadmap: @datakick I would really like to hear your opinion on why the updated is overkill. Because if it is maybe @lesley and @mdekker could use the time/money to build something that is more usefull. Sure, why not. I believe that serious merchants don't need new release every two weeks. That's way too often. We have to remember that this is legacy codebase - Prestashop/Thirtybees source code is big bowl of tangled spaghetti, and every change can cause some bug. So every release is a potential thread, and should be accompanied with thorough re-test of your shop (or at least basic functionality). I'm sure that most merchants that has been running ps/tb for a few years has already experienced some issues with version upgrades. It can be pain, especially when you have many third-party modules. It's tolerable when you are upgrading your shop every 6 month - you just close your shop, and dedicate one weekend for upgrade and thorough retest. But I'm pretty sure most merchants wont be undergoing this task every two weeks, or every month. I think that stability is what merchants value the most. I can see them using this new updater on their dev/test sites to test new codebase. But how many merchants have test sites? From my perspective it's more than enough to release new version once every 6 month. I understand that manually create release can be time consuming -- but how much time can it take, really? Maybe a day or two. How much time will this new updater take? Just my 2 cents... very possibly I'm completely wrong in my assumptions :)

@traumflug said in Thirtybees roadmap: v1.0.5? That’s later this month. There will be a module validator. Maybe some people noticed it, the v1.0.4 release wasn’t as seamless as making a release should be. All the module and theme upgrades got forgotten, even the already distributed ZIP file had to be corrected. So I started an effort to make not forgetting such things much easier. Probably this sounds boring to many, it doesn’t change much to the merchant/customer experience. Still I consider this to be important, because a successful project needs a strong foundation. Thanks for info. Module validator is definitely useful and needed functionality. But it's not a feature, it's a build tool. And that surely doesn't require a release. Anyway, I'd really like to know if there is some sort of short/mid/long-term plan, to see the direction this project is going to. Should we expect mainly bug fixes, or are there some features on the table as well? If so, how are the features prioritized / who decides what will be worked on? How many resources do you have at your (company as a whole) disposal - are we talking about 10 hours a month, or is it 200 hours/month? I understand that you are doing this for free, and that we (community) are not entitled to anything. But still, if you want this project to succeed, you need to commit to your vision and be accountable for it. Otherwise you won't be considered as a serious partner by most merchants (or other developers)

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?