datakick

@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?

@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