Thursday, December 15, 2022
10 changes · master
Enhancements to existing features
Sales users can now see the total order weight when adding shipping to a sales order and can adjust that weight before requesting a carrier rate. This helps produce more accurate shipping quotes and gives users clearer control when carrier pricing depends on shipment weight.
Original PR description
Previously, when adding shipment to sale order, the user did not know the total weight of the order when getting rate of shipping method. This commit shows the total order weight to the user with the ability to set it to any value to get the rate with. TaskId: 2797613 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Bills Dashboard now only shows payment status for posted accounting entries where payment tracking is relevant, such as bills, refunds, invoices, credit notes, and receipts. This prevents entries that do not expect payment from misleadingly appearing as "Not paid," making the dashboard easier to interpret.
Original PR description
Description of the issue/feature this PR addresses: In the Bills Dashboard (Accessible by clicking on the vendor Bill Journal and removing the filter for example), for a lot of different entries the…
Description of the issue/feature this PR addresses: In the Bills Dashboard (Accessible by clicking on the vendor Bill Journal and removing the filter for example), for a lot of different entries the payment status is indicated as "Not paid" even though no payment is expected for those entries. Moreover, this status will not change even though a payment is registered, which is counter intuitive. (Example: a payment is registered -> a payment line PBNK will have the status "Not paid") Desired behavior after PR is merged: The payment status is visible if the entry is "Posted" AND the entry belongs to one of those type: [Bill (BILL), Refund (RBILL), Purchase Receipt (BILL), Invoice (INV), Credit notes (RINV), Sale Receipt (INV)]. If the entry does not meet those criteria, make the payment status invisible. I also kept the previous visibility criteria which stated that the payment status is not visible if the payment state is set to 'Invoicing App Legacy". task id : 3091141 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The product matrix table has been updated to better match the Odoo 16 visual style. This improves usability by fixing dark mode colors and aligning table headers with input fields for a cleaner configuration experience.
Original PR description
The product matrix was recently converted to OWL but the design was not adapted to v16 style. This commit revamps the table to better fits Odoo 16 design. The previous table had issue with wrong color in dark mode and the table head title were not aligned with the inputs. task-3074063 Enterprise PR: https://github.com/odoo/enterprise/pull/34743 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Timesheets settings now offer two clear choices for entering time: Days / Half-Days or Hours / Minutes. This prevents unsupported unit selections and makes it easier for users to understand how timesheet entries can be recorded.
Original PR description
Before this PR, the encoding unit used in the timesheet app was a `Many2one` field and the user can select the UoM to use. However, only 2 units of measure are supported on the Timesheets app, the `Days` and the `Hours` records created in the data. Also, when the encoding is in `Days`, the user cannot directly know he can just set 0, a half-day or a day for a timesheet in the different views of the Timesheets App. This PR replaces the many2one field by a Selection one containing 2 choices, one for `Days / Half-Days` and another one `Hours / Minutes`, to explicitly restrict the choice to the UoMs supported in the Timesheets app. Also, the label of the both choices is more detailed to explicitly notice the user will can select a half-day or day is the encoding unit is `Days / Half-Days` and can edit the hours and minutes on a timesheet when the encoding method selected is `Hours / Minutes`. task-3067111
This update makes Odoo's JavaScript build process list each file's dependencies directly when defining browser modules. This reduces extra work in the browser and should make the underlying asset system more efficient without changing user-facing workflows.
Original PR description
After this commit, the transpiler will add the dependencies of a file to the second argument of the odoo.define(...).
For example:
odoo.define("@test/test", ['@test/dep1', '@test/dep2'], async function (require)
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-prThis change improves the speed of internal view validation during Odoo installation by checking related actions and user groups in batches. It should reduce installation and module setup processing time in complex configurations without changing user-facing behavior.
Original PR description
The main goal is to reduce the processing time it takes for views to be validated during installation. In order to mimic the behavior of the view creations during installation, and to analyze the…
The main goal is to reduce the processing time
it takes for views to be validated during installation.
In order to mimic the behavior of the view creations during installation, and to analyze the performance, I used the below code in the shell:
```py
env.cr.rollback()
domain = [('model', '=', 'res.config.settings')]
views = self.env['ir.ui.view'].search_read(domain, [
'id', 'active', 'arch', 'inherit_id', 'key', 'mode', 'model', 'priority', 'type', 'xml_id'
], order="id ASC")
for view in views:
if view['inherit_id']:
view['inherit_id'] = self.env['ir.ui.view'].browse(view['inherit_id'][0]).xml_id
self.env['ir.ui.view'].browse(reversed([view['id'] for view in views])).unlink()
with odoo.tools.profiler.Profiler():
for view in views:
new_view = self.env['ir.ui.view'].create({
key: self.env.ref(value).id if key in ['inherit_id'] and value else value
for key, value in view.items()
if key not in ['id', 'xml_id']
})
if view['xml_id']:
module, name = view['xml_id'].split('.')
self.env['ir.model.data'].create({
'module': module,
'name': name,
'model': 'ir.ui.view',
'res_id': new_view.id,
})
env.cr.rollback()
```
Using the above, and analyzing the speedscope profile, we can see the lines
```py
action = self.env['ir.actions.actions'].browse(action_id).exists()
```
from `_validate_tag_button`, and
```py
if not self.env['ir.model.data']._xmlid_to_res_id(group.strip(), raise_if_not_found=False):
```
from `_validate_attrs`
take a significant time.
Batching the actions and groups existence
(as recommended as further improvement in the comment which is deleted by this revision), as well as a more efficient algorithm for `_get_node_groups`, reduce the processing time of the views validation.
On my computer, the above code creating all the views for `res.config.settings`, which is an extreme case because the view has 100 inherited views, allows to reduce the validation processing time from 9.42s to 8.18s.
Specifically, `_validate_view` goes from 3.24s to 1.18s, which is about a 270% speed improvement for that method alone.
#### Speedscope profile screenshots:
##### Before
##### After
Regarding the algorithm for `_get_node_groups` itself:
```py
In [0]: %timeit tuple(tuple(n.get('groups').split(',')) for n in node.xpath('ancestor-or-self::*[@groups]'))
10.1 µs ± 91 ns per loop (mean ± std. dev. of 7 runs, 100000 loops each)
In [1]: %timeit groups = [tuple(n.get('groups').split(',')) for n in chain([node], node.iterancestors()) if n.get('groups')];groups.reverse();tuple(groups)
3.46 µs ± 29.2 ns per loop (mean ± std. dev. of 7 runs, 100000 loops each)
```New users who open My Tasks without assigned work will now see default personal stages instead of an empty page. This makes the project task view easier to understand and helps users get started without demo data or prior task assignments.
Original PR description
Currently, when a db is loaded without demo data, or that a user has no task assigned and no personnal stage, the view 'My tasks' is empty. The purpose of this commit is to assign default personnal stage to a user in these case to ease the understanding of new user of what the view can be used for. This commit : - add default personnal stage to user the first time he clicks on the 'My tasks' menu if the user has no personnal stage and no task are assigned to him. task-3047496 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
This update tidies and simplifies the stock barcode app code, making it easier to maintain and less prone to future issues. It removes unused pieces, standardizes internal behavior, and improves how barcode screens manage information without introducing major user-facing changes.
Original PR description
To make the `stock_barcode` cleaner and more maintainable. - Better use of the `Component`'s `props` (set props' description and don't add props dynamically) - Rewrite some methods (`barcodeInfo` because it's a mess, `updateLineQty`, `_updateLineQty` and `updateLineQty` because it seems more natural than `updateLineQty` calls `updateLineQty` who calls `_updateLineQty` instead of the opposite) - Remove dead code - Other things (see commits' message) task-3048127
The product matrix used in sales, purchases, and rentals has been refreshed to better match the Odoo 16 interface. This improves visual consistency, fixes dark mode color issues, and makes table headings align more clearly with input fields.
Original PR description
The product matrix was recently converted to OWL but the design was not adapted to v16 style. This commit revamps the table to better fits Odoo 16 design. The previous table had issue with wrong color in dark mode and the table head title were not aligned with the inputs. task-3074063 Community PR: https://github.com/odoo/odoo/pull/107102
Timesheet date locking is now always active, so users can no longer turn it off in Timesheets settings. This helps enforce validation dates consistently and prevents edits to timesheets that should already be locked.
Original PR description
Before this PR, if the user wants to enable the lock dates feature, he has to enable it in the settings of the Timesheets app. And when it will be enabled the users will not can edit a timesheet if the validation date for the employee linked to the timesheet. This PR removes the setting in the Timesheets app settings and directly enable the feature. It means the user can no longer disabled the feature. task-3067111