Daily updates from Odoo
Friday, October 11, 2019
7 changes · master
Resolved issues and error corrections
This update makes it easier to install and run Odoo on Windows with Python 3.7 by adjusting required third-party packages. It reduces setup failures around image, database, and system dependency packages, helping Windows users get a stable development environment more reliably.
Original PR description
11.0 improving requirements #### Description of the issue/feature this PR addresses: Improving requirements.txt in order to work when platform is 'win32' and python version is 3.7.x #### Current behavior before PR: Executing `pip install -r requirements.txt` the command line (git bash, but also cmd) returns a lot of errors, especially on `Pillow` package. When we execute `odoo-bin` command, we receive other errors due to missing `psycopg2` and other packages. #### Desired behavior after PR is merged: With this PR we have a stable environment, allowing other win32+python3.7 users to setup their environment without headache 😄 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#38428 Forward-Port-Of: odoo/odoo#37745
This update fixes two Point of Sale issues: printed receipts no longer show an unwanted scrollbar, and employee-related user data is loaded correctly when POS HR is installed. This helps ensure cleaner customer receipts and more reliable POS behavior for staff workflows.
Original PR description
[FIX] point_of_sale, pos_hr: Fixes - When pos_hr was installed, `load_models` was called twice for res.users and calls to `load_fields` were not processed correctly. - A scrollbar appeared every time a receipt was printed. To fix this, we put a height of 0 to the div that contains the receipt. html2canvas then had trouble computing the height of the background. There's a height option that can be given to the library but if the logo on the receipt was not loaded yet, the size we computed was wrong. We then compute the height only once the images have been loaded, in the onparsed method. We also remove a CSS class that wasn't used anymore. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#38374
Sales and purchase orders that use year-based numbering will now use the order date, not the current date, when generating their reference number. This prevents orders entered for a different year from receiving an incorrect year in their number, improving accuracy in records and reporting.
Original PR description
[IMP] purchase,sale: Take into account order date for sequence Version of #28921 for upcoming v13 **Steps to reproduce** * Define "Sales Order" sequence for using date ranges checking "Use subsequences per date_range". * Change sequence prefix to "SO/%(year)s/". * Create a sales order with order date in 2019 (a different year than current one). **Current behavior** Got a sales order with 2018 (current year) number. **Expected behavior** Got a sales order with 2019 number. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr cc @Tecnativa Forward-Port-Of: odoo/odoo#37762
This update prevents website visitors from seeing an error page when changing the site language. It resolves a database update conflict in visitor tracking, making multilingual website browsing more reliable.
Original PR description
[FIX] website: fix _update_visitor_last_visit concurrency issues Install the website, install a second language. Switch the language on the website: error 500. The function opened a new cursor, to update website_visitor. It did so at the end of the query dispatch. However when switching the language of the website, the lang is written on the website visitor. This is done at the flush, done at the end (exit) of the query. This is done on the cursor that was used for all the transaction. Therefore that write would systemically fail on a ERROR: could not serialize access due to concurrent update opw 2080986 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#38372
Copying a product variant now duplicates the underlying product template instead of the variant itself, because variants are automatically generated from template settings. This prevents inconsistent product data and makes duplicate product creation behave more predictably.
Original PR description
[MERGE][FIX] product: make copy of variants just copy template Variants are generated depending on the configuration of attributes and values on the template, so copying them does not make sense. For convenience the template is copied instead and its first variant is returned. closes #38151 Forward-Port-Of: odoo/odoo#38303
This fix prevents calendar notifications from crashing when a user's selected language is inactive or missing date and time formats. The calendar now falls back to an active appropriate language, keeping page loads stable for affected users.
Original PR description
[FIX] calendar: handle inactive system language or missing date format It is possible to select "System (English)" as chosen language, or False in v12 or earlier versions. However, if the language has not been activated, then record_lang is an empty recordset, so record_lang.date_format is False, (respectively time_format), and so the formatting crashes. In principle there is a default, but it did not assume that lang could be set but without a date_format. By slightly rewriting it, it also handles this case. Note that if this happens, the calendar notification mechanism generates a crash at each page load. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#38357 Forward-Port-Of: odoo/odoo#38286
Point of Sale sessions connected to payment terminals now wait properly for balance checks before closing, find and print the related receipt correctly, and recover from balance errors such as connection issues. This prevents closing failures, unexpected error screens, and terminal driver crashes that could interrupt store operations.
Original PR description
[FIX] pos_iot: Payment terminals fixes - When closing a session, if a payment terminal is connected, a Balance operation is performed. We didn't wait correctly for the balance to be over before closing the session. - When closing a PoS session connected to a payment terminal, we perform a balance operation and a receipt is printed. The selector used to retrieve the receipt has been changed is point_of_sale but wasn't changed here. The receipt was then not found and there was a traceback. Since the code is now stable the view itself cannot be modified so the new class is added dynamically. - If an error happened during the balance operation (e.g. due to a connection problem) an exception was raised but never caught, making the whole thread of the driver crash and the terminal couldn't be used anymore. We now catch this exception. Forward-Port-Of: odoo/enterprise#6018