Thursday, February 2, 2023
14 changes · master
New functionality added to Odoo
A new icon-style button can now be used to show and change yes/no fields in the web interface. This gives teams a more visual and compact way to represent simple choices, with supporting tests added to confirm it works as expected.
Original PR description
This commit adds a new widget to the field registry. This button is represented with an icon and acts as a boolean field widget. A test file has also been added to verify its behavior. task #3121078 Example image, using a fa-recycle icon: <img width="104" alt="image" src="https://user-images.githubusercontent.com/35101914/213397479-661b9d39-f2e5-40de-88e2-4ee1ede0cbc8.png">
Enhancements to existing features
This change removes old internal access-check methods that are no longer used. It simplifies the core base module and reduces maintenance overhead without changing day-to-day user behavior.
Original PR description
It looks like these methods where an alternative to `has_groups`, but not used since a while. In Odoo 10.0, there is only one hit, in point_of_sale, which has been replaced by `user_has_groups` in 11.0 with revision 34c661111b74145c334ce0cb456a18adccc4a4de In Odoo 9.0, there are a few more hits in base, which have been replaced by `self.env.user.has_group` in 11.0 with revision 4ddc32313996c8cf6e8e6dffd2253aad8a144ccf
Resolved issues and error corrections
The purchase order form now displays the 'Deliver to' field across the full row when storage locations are enabled. This fixes a visual layout issue, making the form clearer and easier to use during purchase order creation.
Original PR description
To reproduce the issue: 1. Install [Inventory], [Purchase] on Apps 2. [Settings]>[Inventory]>[Storage Locations]: enable 3. On [Purchase], Create. 'Deliver to' field is ill-positioned Desired view: use the full width of the row Applicable versions: 16.0 - master opw-314167 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Code cleanup and technical improvements
The Kenyan Tremol e-invoicing module has been updated to use Odoo's newer action framework when sending invoices. This is an internal modernization that helps keep the feature compatible and easier to maintain, with no expected change to day-to-day user workflows.
Original PR description
The purpose of this commit is to convert the client actions 'post_send' to the new architecture. TaskID: 3165941 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
Miscellaneous changes
## Current behaviour You cannot set the Default Analytic Plan for projects in the settings. ## Expected behaviour You should be able to set the default plan, like any other settings. ## Steps to reproduce - Install Accounting, Project, (Timesheets if you want to test project creation with an auto-created analytic account) - Settings > Check Analytic Accounts - Try to change the Default Plan in Settings > Project - Upon saving, the change is lost ## Reason for the problem The `ana
Original PR description
## Current behaviour You cannot set the Default Analytic Plan for projects in the settings. ## Expected behaviour You should be able to set the default plan, like any other settings. ## Steps to…
## Current behaviour You cannot set the Default Analytic Plan for projects in the settings. ## Expected behaviour You should be able to set the default plan, like any other settings. ## Steps to reproduce - Install Accounting, Project, (Timesheets if you want to test project creation with an auto-created analytic account) - Settings > Check Analytic Accounts - Try to change the Default Plan in Settings > Project - Upon saving, the change is lost ## Reason for the problem The `analytic_plan_id` in the project's `res.config.settings` is related to the same field on the `res.company` model. The `analytic_plan_id` that is set on the company upon installing the project module is a non-stored computed field, which makes a call to a `_get_default` -> the field cannot be set. It will always return the first default plan in the sequence. ## Fix Since the field isn't stored (which would have worked if it was), we use `ir.config_parameter` to write and read to it, per company. In master we should just add a `store=True` and write a migration for it? ## Affected versions - 16.0 - saas-16.1 - master --- opw-3127638 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#110298
This fixes how quantities are rounded in manufacturing bills of materials by using Odoo's standard product unit precision. It helps ensure component quantities are displayed and calculated consistently without relying on a missing precision setting.
Original PR description
before this commit, the precision given for the field product_qty in mrp.bom model is Unit of Measure, which is not existing by default in odoo decimal precisions. after this commit, precision will be updated to default Product Unit of Measure precision --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Steps to reproduce (Using Chromium-based browser > v. 108): - Install Survey module - Open 'Feedback Form' survey - Click on 'See Results' button - Try to print the page Issues: - Hundreds of empty pages added when printing. - Charts not fully displayed. Cause: - The chartjs library add some HTML elements not displayed (inside div with class `chartjs-size-monitor`) to handle the resizing of the chart canvas. One of the element has a width and height of 1
Original PR description
Steps to reproduce (Using Chromium-based browser > v. 108): - Install Survey module - Open 'Feedback Form' survey - Click on 'See Results' button - Try to print the page Issues: - Hundreds of empty…
Steps to reproduce (Using Chromium-based browser > v. 108): - Install Survey module - Open 'Feedback Form' survey - Click on 'See Results' button - Try to print the page Issues: - Hundreds of empty pages added when printing. - Charts not fully displayed. Cause: - The chartjs library add some HTML elements not displayed (inside div with class `chartjs-size-monitor`) to handle the resizing of the chart canvas. One of the element has a width and height of 1000000px with an overflow:hidden, but the overflow does not work properly when printing. (Issue introduced in Chrome v. 108, working fine in v. 107 or on any Firefox version) - The chart canvas is not resized to 100% of its parent container and therefore not fully displayed. (Not working in all Chrome and Firefox versions) Solution: Add CSS (with print media rule): - Set style to `display: none` on `chartjs-size-monitor` HTML element. - Set the width and height of the chart canvas to 100%. opw-3109523 Forward-Port-Of: odoo/odoo#111401 Forward-Port-Of: odoo/odoo#110874
--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#111544 Forward-Port-Of: odoo/odoo#111126
Original PR description
--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#111544 Forward-Port-Of: odoo/odoo#111126
Description of the issue/feature this PR addresses: Sometimes, purchase order chatter gets logged with "The ordered quantity has been updated" messages event though the quantities haven't been updated. Current behavior before PR: The chatter gets flooded even though no quantity changed. Desired behavior after PR is merged: The chatter gets updated only if the qty actually changed --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Po
Original PR description
Description of the issue/feature this PR addresses: Sometimes, purchase order chatter gets logged with "The ordered quantity has been updated" messages event though the quantities haven't been updated. Current behavior before PR: The chatter gets flooded even though no quantity changed. Desired behavior after PR is merged: The chatter gets updated only if the qty actually changed --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#109418
Before this PR, recovering from an offline/online switch could take up to 20mn. Indeed, WebSocket are based on TCP that uses FIN packets to close the connection. In case of a sudden loss of internet connection, the client is unaware of the already dead TCP connection. It is up to the browser to assume the connection is dead after some time. This commit solves the issue by closing the connection properly upon the reception of the offline event. When the client is back online, the connec
Original PR description
Before this PR, recovering from an offline/online switch could take up to 20mn. Indeed, WebSocket are based on TCP that uses FIN packets to close the connection. In case of a sudden loss of internet connection, the client is unaware of the already dead TCP connection. It is up to the browser to assume the connection is dead after some time. This commit solves the issue by closing the connection properly upon the reception of the offline event. When the client is back online, the connection is opened again thus allowing an almost instant recovery. At the same time, this PR increases the default `keep_alive_timeout` for websocket connections. Indeed, those re-connections lead to cursor usage bursts and are not required so frequently. Forward-Port-Of: odoo/odoo#111238 Forward-Port-Of: odoo/odoo#111127
Module `pos_restaurant` synchronizes orders between different POS devices. It works by pushing order from POS to server and loading it back. This commit assures that loyalty fields are correctly prepared before returning values to js client. Specifically, many2one fields must be just ids [1] [2], and not `[id, name]`. Similar cleaning is already done in `pos_restaurant` module for `product_id` field [2]. To correctly implement this patch, empty `_prepare_order_line` is added to `point_
Original PR description
Module `pos_restaurant` synchronizes orders between different POS devices. It works by pushing order from POS to server and loading it back. This commit assures that loyalty fields are correctly…
Module `pos_restaurant` synchronizes orders between different POS devices. It works by pushing order from POS to server and loading it back. This commit assures that loyalty fields are correctly prepared before returning values to js client. Specifically, many2one fields must be just ids [1] [2], and not `[id, name]`. Similar cleaning is already done in `pos_restaurant` module for `product_id` field [2]. To correctly implement this patch, empty `_prepare_order_line` is added to `point_of_sale` module to be sure that extension of that method in `pos_loyalty` is not ignored: the method in `pos_restaurant` didn't have `super` call and `pos_loyalty` module doesn't depend on `pos_restaurant` STEPS: * install pos_restaurant, pos_loyalty * prepare gift card * open pos, create order, apply gift card * switch to floor screen and then back to table (order) screen [1]: https://github.com/odoo/odoo/blob/c4b90db77705139333bdf5faf26b12fc120d1661/addons/pos_loyalty/static/src/js/Loyalty.js#L833 [2]: https://github.com/odoo/odoo/blob/c4b90db77705139333bdf5faf26b12fc120d1661/addons/pos_restaurant/models/pos_order.py#L76 Forward-Port-Of: odoo/odoo#111323
In [this forward-port](https://github.com/odoo/enterprise/pull/33666), the split of the file did not raise any conflict, although changes were brought to the original file. This commit brings back the latest changes. Forward-Port-Of: odoo/enterprise#36588
Original PR description
In [this forward-port](https://github.com/odoo/enterprise/pull/33666), the split of the file did not raise any conflict, although changes were brought to the original file. This commit brings back the latest changes. Forward-Port-Of: odoo/enterprise#36588
Currently, when asset/deferred revenue/deferred expense models are imported, an asset/deferred revenue/deferred expense is created instead of a model. This happens because the model creation depends on state, which gets overwritten in `create` starting from 16.0. State should not be overwritten if `default_state` is present in the context. opw-3140284 Forward-Port-Of: odoo/enterprise#36583
Original PR description
Currently, when asset/deferred revenue/deferred expense models are imported, an asset/deferred revenue/deferred expense is created instead of a model. This happens because the model creation depends on state, which gets overwritten in `create` starting from 16.0. State should not be overwritten if `default_state` is present in the context. opw-3140284 Forward-Port-Of: odoo/enterprise#36583
An error about the import credit notes was left in a previous fix and only 2 analytical plans were added, even if there were more in the import file. This has now been corrected. opw-3123726 Forward-Port-Of: odoo/enterprise#36543
Original PR description
An error about the import credit notes was left in a previous fix and only 2 analytical plans were added, even if there were more in the import file. This has now been corrected. opw-3123726 Forward-Port-Of: odoo/enterprise#36543