{"push_id":1008640417,"size":28,"distinct_size":2,"ref":"refs/heads/8.0","head":"aca8a8bebc306af994adaf58e5ec184acec05b79","before":"2230bee0c524f14038c0ea8a95efe9fd7abacf90","commits":[{"sha":"ee33593351a148d0f678b36fc01e8524fe1452b6","author":{"email":"771435c469f83f6aa9c405ac5e1ed06314a94f2d@odoo.com","name":"Nicolas Martinelli"},"message":"[FIX] point_of_sale: round price unit\n\nThe product price unit should be rounded before being used in any\noperation. The PoS calls the method `read` in order to get the necessary\nfields. However, the product price is a non-stored calculated float. In\nold API, such a field is not rounded by the `read` method. It means that\na product price of 28.067 (for example thanks to the use of a pricelist)\nwill be rounded to 28.07 at the server level but not rounded in the PoS\nJS layer.\n\nTo lower the impact of the fix, the rounding is done at the JS level,\nand not in the `_product_price` method.\n\nopw-669024","distinct":false,"url":"https://api.github.com/repos/tvibliani/odoo/commits/ee33593351a148d0f678b36fc01e8524fe1452b6"},{"sha":"68f9f99ed3b8434f7ba621479bce215dce05bdc2","author":{"email":"771435c469f83f6aa9c405ac5e1ed06314a94f2d@odoo.com","name":"Nicolas Martinelli"},"message":"[FIX] models: export of booleans\n\nIn the case of a `raw_data` export, a boolean which has the value\n`False` will not be exported correctly.\n\nThe fix handles the `False` value as a valid value for a field.\n\nopw-666142","distinct":false,"url":"https://api.github.com/repos/tvibliani/odoo/commits/68f9f99ed3b8434f7ba621479bce215dce05bdc2"},{"sha":"4162b8f5fa31cd76fa79c7e810f49b38733a16d4","author":{"email":"9258fa6aabcd2ac002f38c590212f68202bdc103@acsone.eu","name":"Stéphane Bidoul"},"message":"[FIX] account: fiscal position in multi-company environments\n\nProperties depends on with which companies the records\nare browsed.\n\nWhen retrieving the fiscal position as sudo,\nthe company must therefore be enforced within the context,\nto make sure to get the properties from the right\ncompany.\n\nThis method can totally be accessed as sudo,\nwithin the crons for instance.\n\nBefore this revision, the recurring invoices cron\ncould retrieve properties from the wrong company,\nand therefore retrieve the fiscal position of another\ncompany.\n\nCloses #11039","distinct":false,"url":"https://api.github.com/repos/tvibliani/odoo/commits/4162b8f5fa31cd76fa79c7e810f49b38733a16d4"},{"sha":"d4e5019ec74231a92d7759b69c775e5e7577259b","author":{"email":"2907e499a003d1c3ab7944c0a40c6df46e3e3c2f@odoo.com","name":"Nicolas Lempereur"},"message":"[FIX] web: csv export newline for text/html field\n\nCSV export was added in f146e2a and since then newline were not\nexported.\n\nBut new line should be allowed if the string is quoted by \" characters\nwhich is done in Odoo.\n\ncloses #11005\nopw-667853","distinct":false,"url":"https://api.github.com/repos/tvibliani/odoo/commits/d4e5019ec74231a92d7759b69c775e5e7577259b"},{"sha":"9f0120d73bbbc364d8ec04b0e3ad63c75086ba52","author":{"email":"8dd417b68ca1b41b9fae61f535fe0b5d847bdd55@odoo.com","name":"Denis Ledoux"},"message":"[FIX] point_of_sale: Sales Details timezone\n\nThe Sales Details report wizard gives the possibility\nto print the details of the POS orders between two dates.\n\nThe fields in the wizard are of type `date`,\nwhile the orders dates are of type `datetime`.\n\n`00:00:00` and `23:59:59` were naively added\nto the `date_start` and `date_end` (respectively) to\nhandle the case.\n\nBut, this doesn't take care of the user time zone:\nWhen a user choose between February 24th and February 25th,\nit's within his time zone, and therefore, for the search,\nwhere the datetime are in UTC, adding `00:00:00` isn't enough,\nthe dates have to be converted from the user time zone\nto UTC.\n\nopw-6698831","distinct":false,"url":"https://api.github.com/repos/tvibliani/odoo/commits/9f0120d73bbbc364d8ec04b0e3ad63c75086ba52"},{"sha":"9ecd80eaeb28880e989eee10e1a543746e46f036","author":{"email":"56923a0c9ca793c07ff1df1013de5694062a27a6@odoo.com","name":"Jeremy Kersten"},"message":"[FIX] website: sitemap fix length\n\nIterator was consuming the first 45k records.\nSo don't need to specify an offset, because that will ignore the next 45k.\n\nEg: if step of 5, and range(1,13),\nit will only use [1, 2, 3, 4, 5, 11, 12, 13]\n\nCherry-pick/backport of de8296c3a86da5e4ae35edcdb563d317dac32e76","distinct":false,"url":"https://api.github.com/repos/tvibliani/odoo/commits/9ecd80eaeb28880e989eee10e1a543746e46f036"},{"sha":"0eb9772ab8256e341b32537c88dfcc9d0367f9a7","author":{"email":"8dd417b68ca1b41b9fae61f535fe0b5d847bdd55@odoo.com","name":"Denis Ledoux"},"message":"[FIX] calendar: rrule computation of private events\n\nIf an event is private, a bunch of fields\nare hidden for the users not being\nthe owner of the event, even for sudo.\n\nThe fields on which depends the `rrule`\ncomputation were part of the hidden/private\nfields.\n\nIn addition, the `rrule` is always computed\nas sudo. See `_get_rulestring`.\n\nTherefore, the `rrule` of recurrent private events\nwas not correctly computed when the owner wasn't\nthe administrator.\n\nopw-670295","distinct":false,"url":"https://api.github.com/repos/tvibliani/odoo/commits/0eb9772ab8256e341b32537c88dfcc9d0367f9a7"},{"sha":"cfcf8bb31866b223e97a7ced60e425e1c1cbab4f","author":{"email":"56923a0c9ca793c07ff1df1013de5694062a27a6@odoo.com","name":"Jeremy Kersten"},"message":"[FIX] product: avoid traceback when product had no variant.\n\nCompute price with a product template without product product\nraises a traceback: index out of tuple","distinct":false,"url":"https://api.github.com/repos/tvibliani/odoo/commits/cfcf8bb31866b223e97a7ced60e425e1c1cbab4f"},{"sha":"1d269d20f25d29a791bedabc39cdf865215c9887","author":{"email":"302dbdd6b955a21a621d965f08b611353e5e4ddf@gmail.com","name":"Anton Chepurov"},"message":"[FIX] website: sitemap scalability\n\nChecking url_list for duplicates is O(n).\nUse url_set instead of url_list to improve to O(1).\n\nOtherwise sitemap generation even for a million products will never finish.\n\nClose #11106","distinct":false,"url":"https://api.github.com/repos/tvibliani/odoo/commits/1d269d20f25d29a791bedabc39cdf865215c9887"},{"sha":"45d4bd04cb5152e20f6e4c63aaefa240ed7104b9","author":{"email":"1f46e7f017caa89a77c9557ed26b800e8d5d7700@odoo.com","name":"Josse Colpaert"},"message":"[FIX] purchase: the stock should be valued without the taxes included from the purchase order line\n\nFrom issue 660592. (already fixed in v9)  When products are received from a purchase line\nwith taxes included, the cost for the stock valuation (on the stock move) on reception\nshould be without these taxes included.","distinct":false,"url":"https://api.github.com/repos/tvibliani/odoo/commits/45d4bd04cb5152e20f6e4c63aaefa240ed7104b9"},{"sha":"c3a05d05161299e72870be87ad86f313315dafc1","author":{"email":"0e117f2b429bfa19751522a564765b352cb7b946@odoo.com","name":"Christophe Simonis"},"message":"[MERGE] forward port of branch 7.0 up to 9f0120d","distinct":false,"url":"https://api.github.com/repos/tvibliani/odoo/commits/c3a05d05161299e72870be87ad86f313315dafc1"},{"sha":"9f073102ef73acfaab2d9bcdd2e7706af2f0aab0","author":{"email":"e7f5472e9a159f4d404f1091c7e345bf7ac1ddb0@odoo.com","name":"Odoo Translation Bot"},"message":"[I18N] Update translation terms from Transifex","distinct":false,"url":"https://api.github.com/repos/tvibliani/odoo/commits/9f073102ef73acfaab2d9bcdd2e7706af2f0aab0"},{"sha":"feedb0f1f4148daaf05efeae0738f59a78f635a1","author":{"email":"8c699a05c38304827cff61803bc9687ef59fcf8f@odoo.com","name":"Joren Van Onder"},"message":"[FIX] point_of_sale: get the correct logo when using multiple databases\n\nIn an environment where multiple database are available the company_logo\ncontroller in the web module will return a placeholder logo (the Odoo\nlogo) if it can't figure out what db the request belongs to. This logo\nis used on the ESC/POS receipts.\n\nBecause we load the logo with an anonymous CORS request there is no\nauthentication on the request. This is necessary because the POS tends\nto not be served over HTTPS whereas the rest of Odoo is. Without this\ncrossOrigin attribute we could potentially end up in a situation where\nthe canvas is considered tainted by the browser which would prevent us\nfrom extracting the canvas' data with toDataURL(). So removing the\ncrossOrigin attribute is not an option, specifying the db is the next\nbest thing.\n\nopw-670471\n\nnote: in >=9.0 session is a variable defined in the js module instead of\na property on PosModel, so 'self.session.db' should become 'session.db'.","distinct":false,"url":"https://api.github.com/repos/tvibliani/odoo/commits/feedb0f1f4148daaf05efeae0738f59a78f635a1"},{"sha":"63fd73d83d72e66359f167aecfbc6c22ef2bf5d9","author":{"email":"56923a0c9ca793c07ff1df1013de5694062a27a6@odoo.com","name":"Jeremy Kersten"},"message":"[FIX] base_geolocalize: remove useless dependencies\n\nclose #11132","distinct":false,"url":"https://api.github.com/repos/tvibliani/odoo/commits/63fd73d83d72e66359f167aecfbc6c22ef2bf5d9"},{"sha":"f994be0e859be116deb0d75af9720ed6fec3251f","author":{"email":"771435c469f83f6aa9c405ac5e1ed06314a94f2d@odoo.com","name":"Nicolas Martinelli"},"message":"[FIX] report_intrastat, l10n_be_intrastat: period\n\nThe intrastat report period should match the accounting period of the\ninvoice. This might not be the case if the user manually chooses an\naccounting period which does not match the invoice date.\n\nopw-668827","distinct":false,"url":"https://api.github.com/repos/tvibliani/odoo/commits/f994be0e859be116deb0d75af9720ed6fec3251f"},{"sha":"dda904c13392473c0e213078cbb6fc73374a96a0","author":{"email":"8c699a05c38304827cff61803bc9687ef59fcf8f@odoo.com","name":"Joren Van Onder"},"message":"[FIX] point_of_sale: avoid '.' thousands separator issues\n\nWhen we render the payment screen the current value of the current\npaymentline is rendered to a string using\nPaymentline.get_amount_str(). This conversion always rendered numbers\nwith a decimal separator of '.' because it just used\nNumber.toFixed(). This used to be fine but\n5a10903e9b3b3f8143a8f8d3703632e3243efead made the POS adhere to the set\ndecimal and thousands separator. Because of this, the POS now has to\nparse the input with web.parse_value() which takes into account these\nseparators. When parse_value() parses a float it first deletes the\nthousands separators and then replaces the decimal separator with '.'\nbefore it gets cast to a Number.\n\nIn German (and other languages), the '.' is used as a thousands\nseparator which means that it will get deleted by parse_value() so\nyou'll end up with '12.34' being interpreted as '1234'. Because of this\nit is important that we ensure that the default value that appears in\nthe input uses the correct separators.\n\nThe aforementioned issue only occurs when the user changes the default\nvalue in the paymentline. Only then does a conversion take place from\nString to Number. So just clicking on a payment method of type 'Bank'\nand validating it would work fine, only when the payment amount was\nupdated would the issue occur.\n\nFixes #9395\nCloses #10952\n\nnote: this should not be forward-ported to >8.0 because later versions\nuse the rewritten payment screen which is completely different from the\none in 8.0.","distinct":false,"url":"https://api.github.com/repos/tvibliani/odoo/commits/dda904c13392473c0e213078cbb6fc73374a96a0"},{"sha":"3913667396e17075528108ac1031939e6f479ced","author":{"email":"8dd417b68ca1b41b9fae61f535fe0b5d847bdd55@odoo.com","name":"Denis Ledoux"},"message":"[FIX] website: backport of 8d2a3ba12dcec61c7e6afcfd34d00c4167de3baa","distinct":false,"url":"https://api.github.com/repos/tvibliani/odoo/commits/3913667396e17075528108ac1031939e6f479ced"},{"sha":"2ba7fa3c9d439097866e23f7decd1411e4d88ffc","author":{"email":"8dd417b68ca1b41b9fae61f535fe0b5d847bdd55@odoo.com","name":"Denis Ledoux"},"message":"[FIX] website: alternate languages translated URL\n\nThe alternate languages links set in the page `<head>`\nwere not translated in each language, but within the language\nthe user is browsing the website.\n\nThis leaded to SEO referencing issues, as these links leaded\nto (30x) redirections if followed, to translate the URL slug\nwithin the new current language.\ne.g.\n`/fr_FR/shop/product/bose-mini-bluetooth-speaker-7`\nautomatically redirected to\n`/fr_FR/shop/product/mini-haut-parleur-bluetooth-bose-7`\n\nAnd it was the first link which was displayed as alternate link\nwhen being in another language than French, while it should\nbe the second (to avoid the useless redirection).\n\nopw-669979","distinct":false,"url":"https://api.github.com/repos/tvibliani/odoo/commits/2ba7fa3c9d439097866e23f7decd1411e4d88ffc"},{"sha":"b3a3454a2ffab9042c021204d284ac25c5f56aef","author":{"email":"cc7c5be316e48d137cbb549833b85d91034d799d@odoo.com","name":"Martin Trigaux"},"message":"[FIX] stock: duplicated term in .pot","distinct":false,"url":"https://api.github.com/repos/tvibliani/odoo/commits/b3a3454a2ffab9042c021204d284ac25c5f56aef"},{"sha":"acf027ac98cd775e533cc0a0eb208754ba900576","author":{"email":"8c699a05c38304827cff61803bc9687ef59fcf8f@odoo.com","name":"Joren Van Onder"},"message":"[IMP] hw_scale: allow third party USB to serial interfaces\n\nWe support the Mettler Toledo scales which have their own built-in USB\nto serial interface. Due to continuing issues with that built-in\ninterface we will also support the scale configured in raw RS-232 mode\nwhich seems to be more reliable.\n\nThis means that in order to connect the scale you'll need a third party\nUSB to serial interface (unless you have built-in serial interfaces, but\nthe POSBox doesn't).\n\nThe main difficulty this poses is that using this approach we cannot use\nthe name of the interface to find the device. When using the built-in\ninterface of the scale the interface would identify with an ID\ncontaining 'mettler' and 'toledo'. When using a third party interface\nthe ID will instead contain information about the third party\ninterface. To fix this we use a probe-based approach, probing every\navailable serial interface until we find one that returns a response to\nour probe. This approach will work with both third party interfaces and\nthe built-in interface of the scale.\n\nContrary to probe-based approach used in hw_blackbox_be this one is\nslightly more complicated because hw_scale is written in such a way that\nit is 'plug and play', which means that as long as the module is running\nit will continually try to find a scale. This is fine, but we don't want\nto keep sending probes to eg. Fiscal Data Modules, which could lead to\nissues. Therefore we will only probe every device once. When we lose an\nexisting, confirmed connection to a scale we will however keep retrying\nto connect to that particular device.","distinct":false,"url":"https://api.github.com/repos/tvibliani/odoo/commits/acf027ac98cd775e533cc0a0eb208754ba900576"}]}