Wednesday, February 22, 2023
23 changes · master
Enhancements to existing features
Planning can now handle employees or resources that do not have a standard working schedule by treating their availability more flexibly. This helps businesses plan shifts, forecasts, and timesheets for flexible workers without forcing a predefined schedule.
Original PR description
TaskID: 2984138
Knowledge articles can now be saved without storing “Untitled” as their actual title. The interface still shows a translated “Untitled” placeholder when needed, avoiding confusion for users working in different languages.
Original PR description
Currently, we use the value "Untitled" as default value for the title field. When the user clicks on the article title, we will use the first heading of the article as title if the current title is equivalent to the translation of "Untitled". This comparison will obviously go wrong if the users speak different languages. Instead of using "Untitled" as default value, we will allow the article title to be null and we will update the user interface to display "Untitled" when the article does not have any title. The placeholder "Untitled" will then be properly translated in the user's language which was not the case when the value was stored in db. task-3103594
The report filter wording has been updated so users see consistent, clearer labels when choosing to include unposted or draft entries. This reduces confusion and makes report options easier to understand.
Original PR description
Before this PR, in the filter options of the report, when clicking the option "Include Unposted Entries", the label changed for "With Draft Entries" which can be confusing for users. This PR change the labels so that it's more readable and clear for users. Task-id: 3184496
Users can now use KeyPay tax handling in the Australian KeyPay integration, making payroll-related accounting easier to align with KeyPay. The update also corrects a timezone issue for the KeyPay lock date, helping avoid date mismatches when syncing or processing data.
Original PR description
- Allow user to use Keypay tax
Resolved issues and error corrections
The Studio navigation bar now removes actions like "Edit Menu" and "New Model" when users return to the Studio home menu. This prevents confusing options from appearing in the wrong context and makes the Studio experience more consistent.
Original PR description
Be in studio, editing some view. On the navbar, click on the button to go to the studio home menu. Before this commit, the buttons "Edit Menu" and "New Model" were still present. This was because the registry was not listened to at the right time. After this commit, the buttons are removed as they should be if one switches from editing a view to the studio home menu.
Features or functions removed from Odoo
The legacy Awesome Timesheet mobile app integration has been removed to encourage employees to use the standard Timesheet app within Odoo. This simplifies the timesheet experience and focuses support on the main Odoo app instead of an outdated separate mobile tool.
Original PR description
…heet Our intentions is to push people to use the Timesheet app inside Odoo instead of this old mobile app. Task ID: 3168693
Code cleanup and technical improvements
This update modernizes internal spreadsheet components and import paths across document and dashboard spreadsheet features. It should not change day-to-day functionality, but it helps keep the spreadsheet codebase easier to maintain and ready for future improvements.
Miscellaneous changes
The description of the car was always the one of the contract initially when loading the salary configurator, even if another car was selected in the wizard. task-3195886 Forward-Port-Of: odoo/enterprise#37289
Original PR description
The description of the car was always the one of the contract initially when loading the salary configurator, even if another car was selected in the wizard. task-3195886 Forward-Port-Of: odoo/enterprise#37289
This change streamlines how fields update records across several Odoo apps, making the underlying interface more consistent. It is mainly an internal cleanup that should help future maintenance without changing day-to-day user workflows.
Original PR description
This commit, is part of a series of commits that aim to simplifie the concrete fields API. In this commit we will remove update prop from concrete fields. Now each field will directly use this.props.record.update to make changes, and handle the save in fields that need to (e.g. priority). As a consequence of this, the record props need to be mandatory. task-id 3179751
Description of the issue/feature this PR addresses: This PR adds proper icon to the module l10n_rs_reports Current behavior before PR: Module l10n_rs_reports does not have an icon Desired behavior after PR is merged: Module l10n_rs_reports should have an icon Forward-Port-Of: odoo/enterprise#37384
Original PR description
Description of the issue/feature this PR addresses: This PR adds proper icon to the module l10n_rs_reports Current behavior before PR: Module l10n_rs_reports does not have an icon Desired behavior after PR is merged: Module l10n_rs_reports should have an icon Forward-Port-Of: odoo/enterprise#37384
Before this commit there was an error on opening payroll dashboard if auth_totp was not installed. It adds `user_id` key to the session that was used by todo_list component. However session has `uid` key that can be used instead. Forward-Port-Of: odoo/enterprise#37373
Original PR description
Before this commit there was an error on opening payroll dashboard if auth_totp was not installed. It adds `user_id` key to the session that was used by todo_list component. However session has `uid` key that can be used instead. Forward-Port-Of: odoo/enterprise#37373
Forward-Port-Of: odoo/enterprise#37332
Original PR description
Forward-Port-Of: odoo/enterprise#37332
before this commit on clicking the kanban of social.media model, it opens the form view of social.media model, and as a form view is not added for the model, it currently opens a odoo defined form view. Social Marketing --> Configuration -> Social Media after this commit, the kanban will not be clickable as in the previous versions. introduced by: https://github.com/odoo/enterprise/commit/3d5450231857fa8a660b33f60112e888ed27bf52 opened form view:  Forward-Port-Of: odoo/enterprise#36165
Since the introduction of the `l10n_cl_edi_exports` module by https://github.com/odoo/enterprise/pull/34031, the generation of DTEs for exports is handled by that module. That module provides a test for the DTE, and in fact disables the test provided by `l10n_cl_edi`. It makes sense to remove that test altogether, rather than just disable it. Forward-Port-Of: odoo/enterprise#37337
Original PR description
Since the introduction of the `l10n_cl_edi_exports` module by https://github.com/odoo/enterprise/pull/34031, the generation of DTEs for exports is handled by that module. That module provides a test for the DTE, and in fact disables the test provided by `l10n_cl_edi`. It makes sense to remove that test altogether, rather than just disable it. Forward-Port-Of: odoo/enterprise#37337
Forward-Port-Of: odoo/enterprise#37355 Forward-Port-Of: odoo/enterprise#37331
Original PR description
Forward-Port-Of: odoo/enterprise#37355 Forward-Port-Of: odoo/enterprise#37331
In the case of the tax report, depending on the fiscal postion's configuration, it can happen that we are displaying a tax report from a different country than the one from the current company. This lead to incorrect domain computation when trying to audit report line values. With this fix, we are using the current report's country, instead of the company's. task-3199066 Forward-Port-Of: odoo/enterprise#37335
Original PR description
In the case of the tax report, depending on the fiscal postion's configuration, it can happen that we are displaying a tax report from a different country than the one from the current company. This lead to incorrect domain computation when trying to audit report line values. With this fix, we are using the current report's country, instead of the company's. task-3199066 Forward-Port-Of: odoo/enterprise#37335
[FIX] l10n_mx_edi: fix and improve performance on edi_origin search Before this commit: The search domain was using the `like` operator which is a bad idea in this case as we also use the `%` symbol. e.g: `[('l10n_mx_edi_origin', 'like', '04|%')]` Would be transformed in SQL to `... WHERE l10n_mx_edi_origin like '%04|%%' ...` which is not what we want as it was intended to be uses as a `.startswith`. In practice the result will the same in this case as the pipe separator is not use
Original PR description
[FIX] l10n_mx_edi: fix and improve performance on edi_origin search Before this commit: The search domain was using the `like` operator which is a bad idea in this case as we also use the `%` symbol.…
[FIX] l10n_mx_edi: fix and improve performance on edi_origin search
Before this commit:
The search domain was using the `like` operator which is a bad idea
in this case as we also use the `%` symbol.
e.g: `[('l10n_mx_edi_origin', 'like', '04|%')]`
Would be transformed in SQL to `... WHERE l10n_mx_edi_origin like '%04|%%' ...`
which is not what we want as it was intended to be uses as a `.startswith`.
In practice the result will the same in this case as the pipe separator is not
used elsewhere, but the performance decrease.
In this case we should use `[('l10n_mx_edi_origin', '=like', '04|%')]` instead.
After the commit:
Performance analysis (made on 15 as client database ion this version):
On the customer instance with ~3250 records (`account_move where l10n_mx_edi_origin is not null`), to evaluate `_compute_l10n_mx_edi_cancel` of one record:
- Current code: ~1.4 sec
- Changing the 2 `like` into `=like`: ~1.3 sec
- Using 1 `=like`: ~1.4 sec
- Using `order='id desc'`: ~0.1 sec
We can see that the `order` here is crucial as it did allow to make it 10x faster!
the change to `=like` and the "merge of both `like`" didn't improve the query time.
But was kept as the domain is more readable in that way
opw-3164620
Forward-Port-Of: odoo/enterprise#36866Steps to reproduce: 1. set up DHL EU -> International shipping, enable `dutiable material` 2. Make a sale order EU -> UK, with a storable product with qty > 1 3. Validate the delivery 4. In the shipping label, the declared value for customs is qty * subtotal, instead of qty * unit price For example, consider a case with a sale order line with qty = 3, and price = 100. As a result the total should be 300. In the response from DHL, we have: ``` <Dutiable> <DeclaredValue>300.
Original PR description
Steps to reproduce: 1. set up DHL EU -> International shipping, enable `dutiable material` 2. Make a sale order EU -> UK, with a storable product with qty > 1 3. Validate the delivery 4. In the…
Steps to reproduce:
1. set up DHL EU -> International shipping, enable `dutiable material`
2. Make a sale order EU -> UK, with a storable product with qty > 1
3. Validate the delivery
4. In the shipping label, the declared value for customs is qty * subtotal, instead of qty * unit price
For example, consider a case with a sale order line with qty = 3, and price = 100. As a result the total should be 300.
In the response from DHL, we have:
```
<Dutiable>
<DeclaredValue>300.00</DeclaredValue>
<DeclaredCurrency>USD</DeclaredCurrency>
<TermsOfTrade>EXW</TermsOfTrade>
</Dutiable>
```
This is the correct value, but it seems to be ignored when making the label, because we also have:
```
<ExportDeclaration>
<InvoiceNumber>CIN00002</InvoiceNumber>
<InvoiceDate>2023-02-17</InvoiceDate>
<ExportLineItem>
<LineNumber>1</LineNumber>
<Quantity>3</Quantity>
<QuantityUnit>PCS</QuantityUnit>
<Description>Large Cabinet</Description>
<Value>300.00</Value>
<Weight>
<Weight>0.330</Weight>
<WeightUnit>K</WeightUnit>
</Weight>
<GrossWeight>
<Weight>0.330</Weight>
<WeightUnit>K</WeightUnit>
</GrossWeight>
<ManufactureCountryCode>BE</ManufactureCountryCode>
</ExportLineItem>
</ExportDeclaration>
```
The value here should be 100, because it is supposed to be the unit price and not the value of all the quantity done combined.
opw-3167161
Forward-Port-Of: odoo/enterprise#37212Before v13, the report was also considering 'entry' moves: https://github.com/odoo/enterprise/blob/12.0/l10n_be_reports/models/partner_vat_listing.py#L46 . Yet, in 13.0, these 'invoice IS NULL' conditions were badly translated 'move_id IS NULL', which does not make sense, since move_id as a required field on account.move.line. This commit reintroduces the intended behavior. Forward-Port-Of: odoo/enterprise#37230 Forward-Port-Of: odoo/enterprise#37174
Original PR description
Before v13, the report was also considering 'entry' moves: https://github.com/odoo/enterprise/blob/12.0/l10n_be_reports/models/partner_vat_listing.py#L46 . Yet, in 13.0, these 'invoice IS NULL' conditions were badly translated 'move_id IS NULL', which does not make sense, since move_id as a required field on account.move.line. This commit reintroduces the intended behavior. Forward-Port-Of: odoo/enterprise#37230 Forward-Port-Of: odoo/enterprise#37174
The `useState()` in the kanban renderer was erasing the existing state of the KanbanRenderer, in the end, it doesn't make sense to useState for the grass anyway. Forward-Port-Of: odoo/enterprise#37326
Original PR description
The `useState()` in the kanban renderer was erasing the existing state of the KanbanRenderer, in the end, it doesn't make sense to useState for the grass anyway. Forward-Port-Of: odoo/enterprise#37326
When creating a new task as a user with lower privileged and selecting the "Search More..." on the "Worksheet Template" field will output a read access error. How to reproduce ================ 1. As admin, create more than 7 worksheets 2. As demo, open the form to create a new task, on the "Worksheet Template" field click on "Search More..." Actual Behavior =============== The demo user doesn't have the read right on the `model_id` field, this make the compute of `workshee
Original PR description
When creating a new task as a user with lower privileged and selecting
the "Search More..." on the "Worksheet Template" field will output a
read access error.
How to reproduce
================
1. As admin, create more than 7 worksheets
2. As demo, open the form to create a new task, on the "Worksheet
Template" field click on "Search More..."
Actual Behavior
===============
The demo user doesn't have the read right on the `model_id` field, this
make the compute of `worksheet_count` automaticly fail.
Expected Behavior
=================
Giving sudo access on the compute should solves the issue and allows an
unprivileged user to access the "Search More..." without any problem.
opw-3163790
Forward-Port-Of: odoo/enterprise#37013[FIX] hr_payroll: todo_list use component Record This commit aims to fix two bugs in the client action "hr_payroll_dashboard": 1. Opening the debug menu displays an error 2. Editing a note causes a crash Why is this? 1. The useModel hook was created to be used only in a view. Using it in a client action will cause the debug menu to think it is in a view, which will cause the crash. 2. Using the html field in web_editor mode requires passing the setDirty props to it. This will be use
Original PR description
[FIX] hr_payroll: todo_list use component Record This commit aims to fix two bugs in the client action "hr_payroll_dashboard": 1. Opening the debug menu displays an error 2. Editing a note causes a crash Why is this? 1. The useModel hook was created to be used only in a view. Using it in a client action will cause the debug menu to think it is in a view, which will cause the crash. 2. Using the html field in web_editor mode requires passing the setDirty props to it. This will be used when the field is edited. In this case, we use the FieldHtml component without this prop. So we will have a crash when we edit the field. Solution: 1. We will create our model and load it without using the useModel hook. 2. Just pass the setDirty prop to the html field. Forward-Port-Of: odoo/enterprise#37214
Steps to reproduce: - configure a type of approval with no approvers, approvers sequence enabled and a minimum approval greater than or equal to 3; - create an approval with this type; - select 3 approvers; - with the first approver, approve it. Issue: All other approvers have an activity created. While the "approver sequence" parameter is enable. Cause: We only keep the next approver if he is defined in the type of approval. We should keep only the next approver in all cases where
Original PR description
Steps to reproduce: - configure a type of approval with no approvers, approvers sequence enabled and a minimum approval greater than or equal to 3; - create an approval with this type; - select 3 approvers; - with the first approver, approve it. Issue: All other approvers have an activity created. While the "approver sequence" parameter is enable. Cause: We only keep the next approver if he is defined in the type of approval. We should keep only the next approver in all cases where the "approver sequence" parameter is activated. opw-3177434 Forward-Port-Of: odoo/enterprise#37317