Thursday, February 2, 2023
21 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
Odoo now calculates internal field update rules only when needed instead of doing all of them upfront. This significantly reduces installation time for large module sets and speeds up the first request on new workers without changing business behavior.
Original PR description
This patch optimizes the way field trigger trees are computed. Overall, the resulting trigger trees are mostly identical, but they can now be determined one by one, which enables an on-demand…
This patch optimizes the way field trigger trees are computed. Overall, the resulting trigger trees are mostly identical, but they can now be determined one by one, which enables an on-demand approach and partial cache. Before this patch, getting the first trigger tree proceeded as follows: - resolve the dependencies of all fields; - compute the transitive closure of the dependencies of all fields; - store the transitive closure above as field triggers for all fields in a cache. After this patch, getting the first trigger tree proceeded as follows: - resolve the dependencies of all fields; - cache them as direct triggers for all fields; - compute one trigger tree as the transitive closure of the field's triggers, and cache it. This optimization is quite effective during the installation of modules, and is even more effective when the number of fields is large. For instance, a complete installation with all community modules is now takes 25% less time. For a complete installation with all enterprise modules, the installation time is even 30% less! A medium installation is about 16% less time. The optimization also speeds up the first request on a new Odoo worker, since the minimum time for computing a handful of trigger trees is much smaller than before. We have observed slight differences in trigger trees, but they occur in places where the tree has redundant branches, in particular with fields having recursive dependencies. It therefore makes no difference in what is being triggered or invalidated.
Resolved issues and error corrections
This fixes an issue where updating a many-to-many relationship could cause far more related records to be recalculated than necessary. The change reduces unnecessary background work, improving performance for databases with large linked record sets while keeping computed values accurate.
Original PR description
The issue occurs when a computed field depends on a many2many field with a corresponding inverse field on its comodel. Consider two models like ```py class User(models.Model): _name = _description =…
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
The calendar view filter panel now appears on the left side of the screen. This makes the calendar layout more consistent with other Odoo views, helping users navigate filters in a more familiar place.
Original PR description
This commit moves the filter panel of the calendar view to the left of the view to make it more coherent with other views. task: 3164391
The calendar view now behaves more like Google Calendar, making short appointments easier to read and placing events longer than 24 hours in the all-day area. Event cards also show timing details more clearly, helping users scan schedules faster.
Original PR description
This PR change generic calendar view to make it behave more like google calendar. These changes includes : - Scss rules for small event(<15 minutes) so that the title is always readable. On top of that, the top border of a darker color has been removed for these even to allow more space. - Event longer than 24h are now shown in the all day column independent of their 'allday' status - Time is now added in the event description, if the event is shorter than 30 minutes, only the start time is displayed at the end of the line. If the event is longer, the start time and end time are displayed on a new line. task-id : 3114155 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Users can now click action buttons on unsaved draft rows in list views. The system will first save the new record, then run the requested action, reducing interruptions and extra manual steps.
Original PR description
Before this commit, the buttons of the draft record in a list view were disabled. Now, they are enabled and will save (create) the record before executing the button's action. task: 3132960
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
The Sign app now supports using templates when preparing signature requests, making it easier to send consistent documents with less repeated setup. This improves efficiency for teams that send similar agreements or forms regularly.
The issue occurs when a computed field depends on a many2many field with a corresponding inverse field on its comodel. Consider two models like
```py
class User(models.Model):
_name = _description = 'test_new_api.user'
group_ids = fields.Many2many('test_new_api.group')
group_count = fields.Integer(compute='_compute_group_count', store=True)
@api.depends('group_ids')
def _compute_group_count(self):
for user in self:
user.group_count = len(user.group_ids)
class Group(models.Model):
_name = _description = 'test_new_api.group'
user_ids = fields.Many2many('test_new_api.user')
```
When a user is added to a group with
```py
group.write({'user_ids': [Command.link(user.id)]})
```
we expect the field `group_count` to be recomputed on `user` only, but it is actually triggered on *all* the records in `group.user_ids`. This is a real performance issue when there are many records in the relation.
The explanation comes from the fact that
* the framework considers the field `user_ids` is modified on `group`;
* the field `group_count` implicitly depends on `group_ids.user_ids`, which makes it triggered on the users `u` such that `u.group_ids` intersects `group`.
The solution consists in handling the dependencies on inverse many2many field in the field itself. The field no longer adds the implicit dependency on its inverse field in the trigger tree, but instead determines which records in the comodel are actually impacted by the relation change in the method field.write().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
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
This update fixes how subscription-related operations are handled in batches, helping reduce errors when multiple records are processed together. It should make subscription management more reliable for teams working with larger volumes of sales subscriptions.
Original PR description
The goal of this PR is to batch operation for sale_subscription
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