doekia Posted March 13, 2015 Share Posted March 13, 2015 (edited) Hi, Some of you might know or have heard of, on February 26, 2015 some members of the community were invited for technical discussion with the PrestaShop team. You will find below a summary of the points raised, with where it was possible on the field, the decisions that were endorsed. The day was short, given the number of points raised and the atmosphere though studious, nice. https://drive.google.com/open?id=1D9gS---tuK6OOpHaRv8RIPLtN7wSBoKnfvnxXdbxMGA&authuser=0 MEETING MINUTES Prestashop and Community REVISION: 1.0.7 MEETING DATE: 26-FEB-15 ATTENDEES:Xavier du Tertre, Lucas Cerdan, Vincent Terenti, FM de Jouvencel, Charles Wells, Emmanuel Marichal, Fabien Alet, Jérôme Nadaud, Julien Martin, Julien Bourdeau, François Gaillard, Bruno Levêque, Alexandra Even, Xavier Borderie, Gregory Roussac, Sacha Froment, Paulo Dorosario - Atch, Pierre Bouvet - Eolia, Tanguy Jacquet - Mediacom87, J-Marc Morin - doekia, Adonis - prestarocket, Fred - 2FR3, Samy Rabih, Jonathan - PrestaEdit DISTRIBUTION (other than attendees): Purpose of Document To provide a summary of the meeting, focusing on the commitments, emerging issues and current status. This memo not only provides the details of discussion points, it helps to ensure that all attendants receive a consistent interpretation of those points. If any factual errors, misrepresentations or omissions are found in this document, please respond to the author so that the document can be corrected and redistributed. MINUTES & ACTIONS Prestashop Community Introduction / Vision (Bruno Lévêque) To be the best on Github Growth on translations Cover more country specifics – tax / legal / regulation Get more community code vs actual 90% in house More tutorials and starter kit Back to Open Source and community spirit Get more recognition (shop for the mass) Prestashop Community Updates Merchant success It is easy to start a Prestashop, not to be a shop owner. I18N Have one language (english?) bullet proof. Crowdin is complex and requires permanent adjustment to cope with code refactoring.Merchant experience Effort on documentations & tutorials Onboarding and the like may miss its target for becoming merchant unaware / unskilled. Gap from doing few clicks to grasp a merchant aware mindset. Business approach missing. Technical knowledge hidden whilst required (own or 3rd party)A report of "current" versions in use among merchants Performances Not so critical assuming proper server provisioning. Review the display of product page BO and product with combinations in FO Stability Fundamental issues. Poorly educated merchant assume click'n update while the fauna of specific shop cannot be predicted (3rd party modules/themes, overrides, …) Versioning confusing and misguidingRemoval or locking of the update all on AdminModuleController page Auto-upgrade will have 2 options – Update default theme and switch to default – probably sensing the situation (in used theme) to propose the less perturbing default. When no conflict update default is ticked, switch is unticked. Version guidelines to be reviewed and published Charles (CPO) will start publishing a roadmap soon Prestashop Community Modules validation API Validator soon (.phar ?) Close source to prevent study / abuse Under circumstances some exception can be granted The Cloud is the standard platform Validator will adopt Selenium test-unit and profiling On rejection respond thru the link – liaison w/ the causes A contribution kit to emerge Still a lots of manual check – hence mistakes Transparence ? Forum? Comment? Grade ? When “dispute alert” - CC contributor Poor quality or w/o added value (skin tide) About non Addons distributed modules Competition ps_versions_compliancy array of array or ps_versions_tested Thinktank regarding transparence to be conducted Warning on non Addons distributed components not to stigmatise anymore Competition – not with French partner – WorldWide possible to date but Prestashop will compete you soon on such. Prestashop Community Taxes & rounding 1.6.0.13 fixes many issues Yes, impressed by the number of fix, but still major issues – refunds, ecotax, use currency decimal system, ... Assuming international coverage, current code inadequate Unavoidable code refactoring, regression to arise A micro core calculation committee will get a solution to emerge – Charles Wells, FM de Jouvence, JM Morin – delivery: some mature / agile class and evaluation of the effort for integration with minimal disturbance. POC + Agenda + deployment liaising with local regulation experts Prestashop Community Lunch talks 3 states settings on OrderState (e.g: a state does not necessarily mean a change regarding Invoice, but can apply to many states) (FM/JMM) Prestashop Community Themes Sources SAAS on GitHub Mobile JS CCC vs IE8/IE9 Jquery2 has drop IE9 support Theme skeleton Approved and requested Theme override Compatibility (our fault over recent release sorry) Obsoleted bootstrap and misuse Logo mobile Mobile SEO (H1, semantic level, rich snippet) Feature Request (sorry I missed capturing what it was) Better use of bootstrap to come Mobile detect proper use Rich snippet (complex and no agreement amongst experts) – to be reinvestigated Prestashop Community Quality Assurance Unit tests is introduced but not all can be covered to date Big applause Community will help writing Unit-Test Process release to go through unit-test OVH drops less than PHP 5.3 support soon – hence minimal PHP will be 5.4+ Good PSR2 to be investigated Optimisation PHP/SQL phase 1 – Front Office phase 2 – Back office List of Annexes (none) https://drive.google.com/open?id=1D9gS---tuK6OOpHaRv8RIPLtN7wSBoKnfvnxXdbxMGA&authuser=0 Edited March 13, 2015 by doekia (see edit history) 1 Link to comment Share on other sites More sharing options...
doekia Posted March 13, 2015 Author Share Posted March 13, 2015 Here follow the proposed interface for the central calculator under evaluation. <?php /* vim: set noexpandtab sw=8 ts=8 sts=8: */ /* Copyright Jean-Marc MORIN (2015) [email protected] This software is a computer program whose purpose is to compute order accurate amount based on unit prices, series of rules and taxes. This software is governed by the CeCILL-C license under French law and abiding by the rules of distribution of free software. You can use, modify and/ or redistribute the software under the terms of the CeCILL-C license as circulated by CEA, CNRS and INRIA at the following URL "http://www.cecill.info". As a counterpart to the access to the source code and rights to copy, modify and redistribute granted by the license, users are provided only with a limited warranty and the software's author, the holder of the economic rights, and the successive licensors have only limited liability. In this respect, the user's attention is drawn to the risks associated with loading, using, modifying and/or developing or reproducing the software by the user in light of its specific status of free software, that may mean that it is complicated to manipulate, and that also therefore means that it is reserved for developers and experienced professionals having in-depth computer knowledge. Users are therefore encouraged to load and test the software's suitability as regards their requirements in conditions enabling the security of their systems and/or data to be ensured and, more generally, to use and operate it in the same conditions as regards security. The fact that you are presently reading this means that you have had knowledge of the CeCILL-C license and that you accept its terms. */ namespace Calculus; interface ITax { /** @const TAX_CUSTOM for future use (or not) */ const TAX_CUSTOM = 1; /** @const TAX_VAT regular Goods and Services Tax AdValorem */ const TAX_VAT = 2; /** @const TAX_UNIT per unit of sales (probably matchable with other settings) */ const TAX_UNIT = 4; /** @const TAX_TAXEXC the tax computes on tax_excluded_price (e.g: US local/regional taxes or split tax) */ const TAX_TAXEXC = 8; /** @const TAX_WHOLESALE tax applies on wholesale */ const TAX_WHOLESALE = 16; /** @const TAX_GROSS Dunno if this will ever be used (probably on an entire order anyway) */ const TAX_GROSS = 32; /** @const TAX_TURNOVER Actually synonym of TAX_VAT|TAX_NODISCARD */ const TAX_TURNOVER = 514; // /** @const TAX_SPECIES Mask for tax species */ const TAX_SPECIES = 0x0FF; /** @const TAX_FLAGS Mask for tax flags */ const TAX_FLAGS = 0x0FF00; /** @const TAX_TRIGGER Tax kicks on certain level, $extra hold the trigger value (applied on whole price if trigger is negative, price above if trigger positive) e.g: Massachusset's clothing tax */ const TAX_TRIGGER = 256; // /** @const TAX_NODISCARD No tax exclusion permitted (eg:ecotax), the tax is NEVER excluded */ const TAX_NODISCARD = 512; /** @const TAX_NOCHANGE The tax is computed / accumulated but does not change final price (eg:ecotax) */ const TAX_NOCHANGE = 1014; public function manifest(); public function summary(); } interface IDiscount { public function manifest(); public function summary(); } interface IOrderLine { /** * attach a Discount to this Line * * @param string $name * @param number $value - positive float express percent (0.1 = 10%), negative value express amount * @param number $capped - the unit discounted amount that SHOULD NOT be exceeded * @param number $divisor - negative divisor is discrete (discount from n), positive is quantum (discount per n) * @param boolean $force - the amount superceed (replace) actual unit price (only one forced discount per line other are ignored) * * @return OrderLine instance (for fluent coding) */ public function addDiscount($name, $value, $capped = 0, $divisor = 0, $force = false); /** * attach a Tax to this Section * * @param string $code - a tax code, passing similar code will return a uniq instance * @param string $name - a long name * @param number $rate - the rate, positive float express percent (0.1 = 10%), negative value express amount * @param integer $mode - bitmask of ITax::TAX_* constant (e.g: ITax::TAX_VAT|ITax::TAX_NODISCARD) * @param mixed $extra - extra hold amount threshold for ITax::TAX_TRIGGER, when ITax::TAX_CUSTOM implemented will hold the logic patern * @param string $legal - some legal sentense associated with the tax * * @return OrderLine instance (for fluent coding) */ public function addTax($code, $name, $rate, $mode = ITax::TAX_VAT, $extra = null, $legal = null); } interface IOrderSection { /** * attach an OrderLine to the OrderSection * * @param string $uuid a unique line id - mainly for OrderSlip targetting * @param string $ref a reference information (no processsing) * @param string $desc a line description (no processing) * @param number $pricenotax the initial unit price * @param number $qty the quantity * @param number $wholesaleprice[=0] the wholesaleprice (only required if any ITax::TAX_WHOLESALE) * * @return OrderLine instance */ public function addLine($uuid, $ref, $desc, $pricenotax, $qty = 1, $wholesaleprice = 0); /** * attach a Discount to this Section * * @param string $name * @param nimber $value - positive float express percent (0.1 = 10%), negative value express amount * @param number $capped - the unit discounted amount that SHOULD NOT be exceeded * * @return OrderSection instance (for fluent coding) */ public function addDiscount($name, $value, $capped = 0); /** * attach a Tax to this Section * * @param string $code - a tax code, passing similar code will return a uniq instance * @param string $name - a long name * @param number $rate - the rate, positive float express percent (0.1 = 10%), negative value express amount * @param integer $mode - bitmask of ITax::TAX_* constant (e.g: ITax::TAX_VAT|ITax::TAX_NODISCARD * @param mixed $extra - extra hold amount threshold for ITax::TAX_TRIGGER, when ITax::TAX_CUSTOM implemented will hold the logic patern * @param string $legal - some legal sentense associated with the tax * * @return OrderSection instance (for fluent coding) */ public function addTax($code, $name, $rate, $mode = ITax::TAX_VAT, $extra = null, $legal = null); /** * attach a Voucher to this Section * really a semantic alias for addDiscount() accepting only negative amount * * @param string $name * @param number $value - negative amount * * @throws Exception if value is not negative * * @return OrderSection instance (for fluent coding) */ public function addVoucher($name, $value); } interface IOrder { /** @const TAXINC the Order compute all taxes */ const TAXINC = 1; /** @const TAXEXC the Order ignore taxes but the ITax::TAX_NODISCARD */ const TAXEXC = 2; /** * * @param integer $use_tax one of IOrder::TAXINC or IOrder::TAXEXC * @param number $precision[=2] number of significant decimals * @param callable $round_func[=null] a rounding user defined function rounder($value,$precision), default is internal libc agnostic round() in mode PHP_ROUND_HALF_UP */ public function __construct($use_tax = IOrder::TAXINC, $precision = 2, $round_func = null); /** * * @param string $manifest a serialized manifests * @param string[] $refunds[] array of serialized manifests */ public function __from_manifest($manifest, array $refunds); /** * attach an OrderSection to this Order * * @param string $name[='products'] name of the section (e.g: addSection('shipping') ) * * @return OrderSection instance */ public function addSection($name = 'products'); /** * attach a Discount to this (whole) Order * * @param string $name * @param nimber $value - positive float express percent (0.1 = 10%), negative value express amount * @param number $capped - the unit discounted amount that SHOULD NOT be exceeded * * @return Order instance (for fluent coding) */ public function addDiscount($name, $value, $capped = 0); /** * attach a Tax to this (whole) Order * * @param string $code - a tax code, passing similar code will return a uniq instance * @param string $name - a long name * @param number $rate - the rate, positive float express percent (0.1 = 10%), negative value express amount * @param integer $mode - bitmask of ITax::TAX_* constant (e.g: ITax::TAX_VAT|ITax::TAX_NODISCARD * @param mixed $extra - extra hold amount threshold for ITax::TAX_TRIGGER, when ITax::TAX_CUSTOM implemented will hold the logic patern * @param string $legal - some legal sentense associated with the tax (default is $name) * * @return Order instance (for fluent coding) */ public function addTax($code, $name, $rate, $mode = ITax::TAX_VAT, $extra = null, $legal = null); /** * attach a Voucher to this (whole) Order * really a semantic alias for addDiscount() accepting only negative amount * * @param string $name * @param number $value - negative amount * * @throws Exception if value is not negative * * @return Order instance (for fluent coding) */ public function addVoucher($name, $value); /** * create an OrderRefund based on this Order * * @return OrderRefund instance (for fluent coding) */ public function addOrderRefund(); public function manifest(); public function summary(); } interface IOrderRefund { /** * refund one OrderLine * * @param string $uuid a unique line id * @param number $qty quantity to refund (positive quantity) * * @throws Exception if $qty is negative or $uuid does not exist or exhausted * @return OrderRefund instance (for fluent coding) */ public function refundLine($uuid, $qty = 1); public function manifest(); public function summary(); } 1 Link to comment Share on other sites More sharing options...
doekia Posted February 27, 2016 Author Share Posted February 27, 2016 This followup should have been really a new topic called PrestaShop Does No Care Your Business,but having the history will help everyone that like to dig further. One year ago, PrestaShop responded after months of a campaign aiming to fix prices bad computations, with poor to no success that it will be fixed soon, and that we (the people complaining) should shut our mouth up, they will master a fix seamlessly. A month later a private road-map (under NDA) was presented including numerous enhancements on progress and a task spreading all across the year regarding computation, pricing, invoice and the various aspect of those core business needs. Without entering this road-map that we cannot disclose, let's have a status on the latest 1.6.1.4 to figure-out how good it behave regarding this central concern for e-merchant having choose to use Prestashop. Pricing, invoice, rounding, basic calculation is still really wrong soon scenario are not as per the demo shop. Multi-taxes, cumulative taxes, voucher, partial reimbursement to name a few. Despite promises and other various announcements PrestaShop is far from been able to cope with local regulations - not in UE, not in Canada, not in US, ... The wobbly-wobbly approach leads to numerous series of bug when it goes to the payment checkout phase. Most Paypal issues reported are related in some aspect to calculation changing for every minor version. Not only the module should adapt, but they should be smart enough to deal with some impossible scenario such as Cloud's version been not updatable, and for at least a few not even public release. The cart rule - one of the major aspect of in shop customer engagement - is so buggy that again you should refrain from using but the basic. Even the basic can bankrupt businesses - Offering a gift on the very first order of every customer for instance when gift price is zero and customer can win forever. Functionning feature get pruned off without notice for no reason, against business need (multi-shipping, voucher usable shipping included, ability to disable canonical redirect, language selection on BO, .htaccess regen, ...). Unusable or inappropriate recurrenly mentionned functionnalty, although central or business critical are ignored by code refactoring to privilege useless "must have" one's. One monolytic does everything Product page you need a screen the size of a baseball field, and a massive dose of patience. Unbearable Carrier range / fee definition. Multishops... any multi-thingy are pile of bug. In the mean time, onboarding, gamification, ... Version released, stamped stable when no descent test have ever been conducted. Chief Product Officer, Charles Wells, joined the team with proven record and experience. After the fiasco of version 1.6.0.12, .13, .14, releases 1.6.1.0, .1, .2, .3 was given a release-candidate try period. Either Chas pushed too hard or get tired of such, he left the team. Soon after, the 1.6.1.4 was pushed yet again w/o RC period. The version 1.6 after been on-air for 2 years, is barely stable, that it get abandoned and attention is turned to the new most luxurious, technology arrogant, superlative driven 1.7 - core needs is yet again disregarded. PrestaShop approach is today on sexy, buzzable, so called revolutionary, heavily marketable features. The core business need is not of any concern. If it is not addon-able. If it is not a sufficient/immediate factor of revenu. Despite the fact that PrestaShop drain millions of revenu due the solution, core development team is about 5 persons. Yes, for 1 millions of lines of code and as per the marketing figures 400 thousand more shops. 2 Link to comment Share on other sites More sharing options...
Recommended Posts