Thursday, December 15, 2022
51 changes · master
New functionality added to Odoo
Support teams can now add logging to automated server actions, including optional stack details, to help trace unexpected data changes. This makes it easier to investigate hard-to-reproduce issues without changing normal business workflows.
Original PR description
This PR is mainly meant for the support. Note that the `stack_info` is purposefully accessible to add some stack trace in the logs. Example of support tickets where it can be useful: A certain field of a particular model change it's value with no particular pattern and way to reproduce. With this commit, we can now create an automated actions on the model update trigger to dump the current stack that will lead us on the action that did trigger it. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
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
Resolved issues and error corrections
This update aligns several internal method definitions across Odoo modules so they behave consistently when called in newer supported ways. It reduces compatibility issues for customizations and adds automated checks to help prevent similar problems in future changes.
Features or functions removed from Odoo
An obsolete language-related function was removed from the core base module. This simplifies maintenance and reduces reliance on deprecated internal code, with no expected impact for everyday users.
Original PR description
--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
task# 3054440 Description of the issue/feature this PR addresses: Text content of buttons to manipulate tables are missing the _t. Current behavior before PR: Text content of table buttons (move left, insert right, etc) are missing the _t() in order to become translatable strings. Desired behavior after PR is merged: Such text content is wrapped in _t() and therefore translatable. New entries in the .pot files were made for that. Forward-Port-Of: odoo/odoo#105806
Original PR description
task# 3054440 Description of the issue/feature this PR addresses: Text content of buttons to manipulate tables are missing the _t. Current behavior before PR: Text content of table buttons (move left, insert right, etc) are missing the _t() in order to become translatable strings. Desired behavior after PR is merged: Such text content is wrapped in _t() and therefore translatable. New entries in the .pot files were made for that. Forward-Port-Of: odoo/odoo#105806
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
Original PR description
*: base, account, crm, hr, hr_attendance, test_access_rights The various public methods of the ORM can be override in other models, those overrides sometime don't implement the exact same signature…
*: base, account, crm, hr, hr_attendance, test_access_rights The various public methods of the ORM can be override in other models, those overrides sometime don't implement the exact same signature as the original method in the ORM. In this work we sanitize all the overrides to ensure a better compatibility. The background objective is to make it possible to call any public method using kwarg: `search(domain=[...])`. * `search`, the first parameter was renamed from `args` to `domain` in 0e9adf7 but the overrides were not updated. * `invalidate_models` and `invalidate_recordset`, a new `flush=True` parameter was introduced in 9c3b9a4 but the overrides were not updated. * `update`, there is a clash between the `update` method responsible for writing on a record and `update` in bus responsible to update the user presence. The bus method has been renamed so it doesn't clash with the ORM. This sanitization comes with a new linter that verifies that all overrides of BaseModel public methods share a compatible signature. The linter has been disabled for `init` and `update` until the deprecation expires. 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
Button text for copying payment links now uses the standard label field, so it is included in translation workflows. This helps users see the correct localized text in multilingual Odoo environments.
Original PR description
Before this commit, the text of a `CopyClipboardButtonField` could be edited with a `label` option. But this label was never translated. After this commit, the field `string` is used instead to rename the button. This is automatically exported for translatation. task-3054813
Fixed payment provider fees are now shown as monetary amounts and converted into the selected payment currency. This helps businesses display and calculate payment fees accurately for customers using different currencies.
Original PR description
Payment fees appeared as float (and not monetary) in the Payment provider form and were not converted into the chosen payment currency task-2854143 See also: - https://github.com/odoo/upgrade/pull/4106
Duplicating a field service task now keeps the worksheet templates manually set on its subtasks. This prevents teams from losing task-specific worksheet setup and having it overwritten by the project default.
Original PR description
Steps to reproduce: - We have to go to any project with subt-tasks and workseets enabled. - We create a new task with a few sub-tasks inside and select manually a worksheet template for each sub-task. - We duplicate this task. Issue: When we duplicate the task we lose the sub-tasks worksheet templates and they're replaced by the default project worksheet template. Solution: Following the same flow of computing the worksheets templates in project , we have to add the proper condition to not lose the worksheet template of the task if it has one already. This bug affects all versions from saas-15.2 until master. opw-3058207
Cleaned up a misleading test comment in the HR mobile area that referenced a dependency which does not exist. This prevents internal asset processing from treating the comment as a real dependency, helping avoid unnecessary test or loading issues.
Original PR description
In order to avoid extracting dependencies from the js at each asset load, in task 3062390 we decided to extract the dependencies directly into the js_transpiler. This implies that all requires are considered as dependencies. Even those present in comments, it is therefore necessary to avoid writing a require(...) with an invalid dependency in a comment.
This update aligns method definitions in affected modules with the core system to prevent compatibility issues when features call shared model operations. It reduces the risk of errors in customized or extended business workflows and adds automated checks to catch similar issues in the future.
Original PR description
*: knowledge The various public methods of the ORM can be override in other models, those overrides sometime don't implement the exact same signature as the original method in the ORM. In this work we sanitize all the overrides to ensure a better compatibility. The background objective is to make it possible to call any public method using kwarg: `search(domain=[...])`. * `search`, the first parameter was renamed from `args` to `domain` in 0e9adf7 but the overrides were not updated. * `invalidate_models` and `invalidate_recordset`, a new `flush=True` parameter was introduced in 9c3b9a4 but the overrides were not updated. This sanitization comes with a new linter that verifies that all overrides of BaseModel public methods share a compatible signature.
`sale` module uses custom field class to provide extra features. Particularly, it makes product field clickable depending on SO status. However, this feature doesn't work in Studio context. Specifically, parent record might be not `Record` instance for `sale.order`, but `StaticList` instance for `sale.order.line`, which doesn't have `isReadonly` method. Fix it by that `isReadonly` is not `undefined`. We don't need to make product field clickable in Studio anyway. opw-3098768 opw-3099942
Original PR description
`sale` module uses custom field class to provide extra features. Particularly, it makes product field clickable depending on SO status. However, this feature doesn't work in Studio context. Specifically, parent record might be not `Record` instance for `sale.order`, but `StaticList` instance for `sale.order.line`, which doesn't have `isReadonly` method. Fix it by that `isReadonly` is not `undefined`. We don't need to make product field clickable in Studio anyway. opw-3098768 opw-3099942 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#107846
Commit [1] introduced the shape system. This system was able to chain shapes depending on the shape of the previous sibling element. Unfortunately, if the shape selected on the sibling was the last shape available, clicking on the toggle shape button would result in nothing happening. This commit fixes that by defaulting to the first shape if no possible shapes are given by the sibling. [1]: https://github.com/odoo/odoo/commit/b84e0af742c51b88b4c108ebec2d0c7fff4b7483 opw-3082292 For
Original PR description
Commit [1] introduced the shape system. This system was able to chain shapes depending on the shape of the previous sibling element. Unfortunately, if the shape selected on the sibling was the last shape available, clicking on the toggle shape button would result in nothing happening. This commit fixes that by defaulting to the first shape if no possible shapes are given by the sibling. [1]: https://github.com/odoo/odoo/commit/b84e0af742c51b88b4c108ebec2d0c7fff4b7483 opw-3082292 Forward-Port-Of: odoo/odoo#107951
Steps to reproduce the bug: - Install mrp - Enable Allocation Report for Manufacturing Orders in settings - Go to WH/MO/00003 from the demo data in runbot - Click on the “Allocation” button Problem: Traceback is triggered, we try to format the info from the source ("Manufacturing order") and send it in an HTML request, but we access the `partner_id` field, while this field does not exist in the "mrp.production" model: https://github.com/odoo/odoo/blob/f310d8f16b57c776ad92406bd52daa707
Original PR description
Steps to reproduce the bug:
- Install mrp
- Enable Allocation Report for Manufacturing Orders in settings
- Go to WH/MO/00003 from the demo data in runbot
- Click on the “Allocation” button
Problem:
Traceback is triggered, we try to format the info from the source ("Manufacturing order") and send it in an HTML request, but we access the `partner_id` field, while this field does not exist in the "mrp.production" model:
https://github.com/odoo/odoo/blob/f310d8f16b57c776ad92406bd52daa707ad45a88/addons/stock/report/report_stock_reception.py#L373-L374
The first element is always considered as a `stock.picking` but it can be the `mrp.production`
opw-3063172
opw-3086714
Forward-Port-Of: odoo/odoo#107646Steps to reproduce the bug: - log in as admin - Go to users, edit Michel Admin - Add “Manage Multiple stock Locations” permission - Create a purchase order: - Add any storable product - confirm PO - Receive product Problem: The "Deliver To" field is misaligned, and the following fields are off by 1 column as well. Because the “reminder” field is made invisible when `effective_date` is not false but its label is still visible, so an empty place is still present in the view
Original PR description
Steps to reproduce the bug:
- log in as admin
- Go to users, edit Michel Admin
- Add “Manage Multiple stock Locations” permission
- Create a purchase order:
- Add any storable product
- confirm PO
- Receive product
Problem:
The "Deliver To" field is misaligned, and the following fields are off by 1 column as well. Because the “reminder” field is made invisible when `effective_date` is not false but its label is still visible, so an empty place is still present in the view
Solution:
If the “reminder” field is invisible, its label should also be hidden
opw-3097481
Forward-Port-Of: odoo/odoo#107945Since [this commit], when a user had configured a recaptcha, he got a traceback when he added the legal text specific to the recaptcha on a form or a newsletter. The bug was visible by following these steps: - Set up a recaptcha on a DB - Drop a form block on a website page - Click on the submit button - Toggle the Show ReCaptcha option => A traceback is displayed because the template is not found. The fix for this bug is just to define the template as a common asset. [this commit]:
Original PR description
Since [this commit], when a user had configured a recaptcha, he got a traceback when he added the legal text specific to the recaptcha on a form or a newsletter. The bug was visible by following these steps: - Set up a recaptcha on a DB - Drop a form block on a website page - Click on the submit button - Toggle the Show ReCaptcha option => A traceback is displayed because the template is not found. The fix for this bug is just to define the template as a common asset. [this commit]: https://github.com/odoo/odoo/commit/39ea7a1fab257ab46a8faf97eea75cc37f8c43e5 opw-3076185 Forward-Port-Of: odoo/odoo#107595
- Steps to reproduce: - Install `HR` module - Go to Employees - Open the Employee ('' Ex: Abigail Peterson') - Archive - Check `Detailed Reason` in Employee Termination wizard - Issue: Currently, the detailed reason appears in a small width. In this commit, we will show the detailed reason in full width. Forward-Port-Of: odoo/odoo#108014
Original PR description
- Steps to reproduce:
- Install `HR` module
- Go to Employees
- Open the Employee ('' Ex: Abigail Peterson')
- Archive
- Check `Detailed Reason` in Employee Termination wizard
- Issue:
Currently, the detailed reason appears in a small width.
In this commit, we will show the detailed reason in full width.
Forward-Port-Of: odoo/odoo#108014Previously, it was only possible to upload a bill, so the partner_id was read from the vendor in the imported file. Now, it is also possible to upload a file to create an invoice, so we need to be able to decode the customer in the imported file. opw-3072989 Forward-Port-Of: odoo/odoo#106909 Forward-Port-Of: odoo/odoo#106765
Original PR description
Previously, it was only possible to upload a bill, so the partner_id was read from the vendor in the imported file. Now, it is also possible to upload a file to create an invoice, so we need to be able to decode the customer in the imported file. opw-3072989 Forward-Port-Of: odoo/odoo#106909 Forward-Port-Of: odoo/odoo#106765
[FIX] website: fix opening shared documents from the WebsitePreview Before this commit, following this flow: - From the documents app, click on the "share" icon of a document, - In the website builder, in edit mode, paste the link in the link tools, - Save and click on the link, => There is a traceback coming from cross-origins errors with the iframe. These documents should be opened in the top window, as it does not make sense to open the pdf viewer inside the iframe. This is define
Original PR description
[FIX] website: fix opening shared documents from the WebsitePreview Before this commit, following this flow: - From the documents app, click on the "share" icon of a document, - In the website…
[FIX] website: fix opening shared documents from the WebsitePreview Before this commit, following this flow: - From the documents app, click on the "share" icon of a document, - In the website builder, in edit mode, paste the link in the link tools, - Save and click on the link, => There is a traceback coming from cross-origins errors with the iframe. These documents should be opened in the top window, as it does not make sense to open the pdf viewer inside the iframe. This is defined in the website module, to avoid creating a website_documents module just to patch the WebsitePreview._isTopWindowURL method. [1]: 44da4bf task-2687506 ----- [FIX] website: fix opening .xml pages from the WebsitePreview Before this commit, following this flow on the website builder: - Add a new .xml page, - From the page manager, click on the record to open it, => There is a traceback as the website service parses the html document as an editable one. This commit fixes the test introduced in [1] to hide edit options on non editable documents. The test is updated to check: 1/ If there is a dataset (the document of an XML file opened on Firefox will not have a dataset), 2/ If the dataset has a websiteId key. It is the case only for website pages, rendered using the 'website.layout' template, and not for other files (js, css, scss, less, xml, csv). [1]: https://github.com/odoo/odoo/commit/44da4bfcc30ca4fe78a1e0c5cb2f9f498ba6e72e task-2687506 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#102919
**Current behavior before PR:** Use the top right arrow to navigate from a record that is in the draft stage to the record that is in stage sent and use the arrow to come back to a record that is in the stage draft. The theme selector is added to the sidebar. **Desired behavior after PR is merged:** Now theme selector will not be added to the sidebar. Task-3016118 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: od
Original PR description
**Current behavior before PR:** Use the top right arrow to navigate from a record that is in the draft stage to the record that is in stage sent and use the arrow to come back to a record that is in the stage draft. The theme selector is added to the sidebar. **Desired behavior after PR is merged:** Now theme selector will not be added to the sidebar. Task-3016118 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#104649
**Current behavior before PR:** There is not any message displayed when the search was performed on icons but not received any results. **Desired behavior after PR is merged:** Now there is a no-content message so that users know that the search was performed. Task: 2745855 Forward-Port-Of: odoo/odoo#107439 Forward-Port-Of: odoo/odoo#107199
Original PR description
**Current behavior before PR:** There is not any message displayed when the search was performed on icons but not received any results. **Desired behavior after PR is merged:** Now there is a no-content message so that users know that the search was performed. Task: 2745855 Forward-Port-Of: odoo/odoo#107439 Forward-Port-Of: odoo/odoo#107199
Steps to reproduce: 1. Create a new tax (TAX1) with a lower sequence than VAT(15%). 2. Check Affect Base of subsequent taxes. 3. Create an invoice, add a line with a product and both taxes. 4. Remove the invoice line. 5. Check Journal Items tab: a VAT line is still there with an amount Bug: When we create an invoice line with (affecting + affected) taxes, 4 Journal items are created, including the affecting tax line having the affected tax as tax id. When we remove the invoice li
Original PR description
Steps to reproduce: 1. Create a new tax (TAX1) with a lower sequence than VAT(15%). 2. Check Affect Base of subsequent taxes. 3. Create an invoice, add a line with a product and both taxes. 4. Remove the invoice line. 5. Check Journal Items tab: a VAT line is still there with an amount Bug: When we create an invoice line with (affecting + affected) taxes, 4 Journal items are created, including the affecting tax line having the affected tax as tax id. When we remove the invoice line, the system sync the dynamic lines, recomputing all the taxes to check what to create/write/delete As one of the tax entries has a tax it will be left as a needed line while it should be removed. FIX: avoid computing `_compute_all_tax` for tax lines Forward-Port-Of: odoo/odoo#107776
Forward-Port-Of: odoo/odoo#108019
Original PR description
Forward-Port-Of: odoo/odoo#108019
A typical Odoo worker is able to handle ~20 requests per second. With a default limit to 8192, it means that the worker is recycled after 8192 / 20 = 409s ~ 7 minutes. There is no reason to recycle a worker that often, since there are other means of limiting the resources allocated to a worker such as the memory limit. We increase the default limit request to 65535, therefore the lifetime of a worker should be extended to ~1 hour in peak times. Description of the issue/feature this PR a
Original PR description
A typical Odoo worker is able to handle ~20 requests per second. With a default limit to 8192, it means that the worker is recycled after 8192 / 20 = 409s ~ 7 minutes. There is no reason to recycle a worker that often, since there are other means of limiting the resources allocated to a worker such as the memory limit. We increase the default limit request to 65535, therefore the lifetime of a worker should be extended to ~1 hour in peak times. 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#107922
When creating an employee with an associated user, the work email of the employee is copied from the user (or actually the partner associated with the user). However since this [commit], both the `mobile_phone` and `work_email` fields on the employee are computed fields based on a linked partner in the `work_contact_id` field. This partner is created on the fly if it did not previously exist. Both of these behaviors interact in such a way, that the linked partner of the employee is created
Original PR description
When creating an employee with an associated user, the work email of the employee is copied from the user (or actually the partner associated with the user). However since this [commit], both the…
When creating an employee with an associated user, the work email of the employee is copied from the user (or actually the partner associated with the user). However since this [commit], both the `mobile_phone` and `work_email` fields on the employee are computed fields based on a linked partner in the `work_contact_id` field. This partner is created on the fly if it did not previously exist. Both of these behaviors interact in such a way, that the linked partner of the employee is created automatically using the email from the linked partner of the user. This is a bug, since both linked partners of the employee and the user should be the same. The bug is easily resolved by adding the `work_contact_id` field directly to the values dict for the creation of the employee (instead of the `work_email`). Reproduction steps: the bug can be easily triggered by repeatedly installing and uninstalling the employees app. An extra partner gets created for each employee in the master or demo data, after each install/uninstall cycle. [commit]: https://github.com/odoo/odoo/commit/3c6060b7bbe9c67aca8073ef43c1e89fb7e820ca opw-3031187 Forward-Port-Of: odoo/odoo#103792
The - Split Expense - feature was introduced in odoo/odoo#90770 In this commit we fix the following bug, related to it: Steps to reproduce: - Create expense with tax_ids. - Click on - Split expense on the expense form. From the first hr.expense.split line remove the tax_ids. Rename it as '1', so that it is easier to find it back for checking later on. - Click on - Expense split on the wizard. Check the resulting expenses. Specifically, the one with the name '1'. Current behavi
Original PR description
The - Split Expense - feature was introduced in odoo/odoo#90770 In this commit we fix the following bug, related to it: Steps to reproduce: - Create expense with tax_ids. - Click on - Split expense…
The - Split Expense - feature was introduced in odoo/odoo#90770 In this commit we fix the following bug, related to it: Steps to reproduce: - Create expense with tax_ids. - Click on - Split expense on the expense form. From the first hr.expense.split line remove the tax_ids. Rename it as '1', so that it is easier to find it back for checking later on. - Click on - Expense split on the wizard. Check the resulting expenses. Specifically, the one with the name '1'. Current behavior - The tax_ids field for the first expense (with the name '1') is still populated. Expected - The tax_ids field for the first expense should be empty. On top of that, we introduce the tests that check Split Expense flow. task - 2831024 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#107807
This is a rare case where method _read() raises a MissingError instead of just ignoring it. The issue is triggered by several conditions on a model M: - at least one ir.rule on M with a domain using a column field on M; - one deleted record Y which is in the prefetch set of a record X; - one reads a non-column field on record X. Fix method _read() to manage that case. It adds an extra call to exists() in that case, but adds no overhead in the general case. Forward-Port-Of: odoo/o
Original PR description
This is a rare case where method _read() raises a MissingError instead of just ignoring it. The issue is triggered by several conditions on a model M: - at least one ir.rule on M with a domain using a column field on M; - one deleted record Y which is in the prefetch set of a record X; - one reads a non-column field on record X. Fix method _read() to manage that case. It adds an extra call to exists() in that case, but adds no overhead in the general case. Forward-Port-Of: odoo/odoo#107996 Forward-Port-Of: odoo/odoo#107883
*: base_setup, hr_timesheet, mail, partner_autocomplete, web_tour Start odoo without -d and with a --dbfilter that allows multiple databases. Via JSON-RPC access the /web/session/authenticate route providing a non-filtered database and valid credentials. Traceback, `request.env` is None. Since httpocalypse the initialization of the ORM (cursor, registry, environment) is greedy. It means that the connection to the database is established very early during the request routing or skip altoget
Original PR description
*: base_setup, hr_timesheet, mail, partner_autocomplete, web_tour Start odoo without -d and with a --dbfilter that allows multiple databases. Via JSON-RPC access the /web/session/authenticate route…
*: base_setup, hr_timesheet, mail, partner_autocomplete, web_tour Start odoo without -d and with a --dbfilter that allows multiple databases. Via JSON-RPC access the /web/session/authenticate route providing a non-filtered database and valid credentials. Traceback, `request.env` is None. Since httpocalypse the initialization of the ORM (cursor, registry, environment) is greedy. It means that the connection to the database is established very early during the request routing or skip altogether in case no dbname was known at that time. This contrast with prepocalypse where the various ORM thingies were lazily setup the first time they were accessed. This changement has an important implication regarding authentication. In prepocalypse, thanks to the lazy approache, a cursor/registry/env would be setup on the database you just login upon using the `request.env` for the first time. This was very nice in this regard but had other problems. Since httpocalypse such operation is no more possible. Devs must initialize and use their own cursor/registry/env in case they authenticate on another database than the one `request.cr` is (maybe) connected to. The `/web/session/authenticate` controller is an example of such case. It crates its own cr/registry/environment after authentication. The problem the controller uses `ir.http.session_info` and that not all overrides were updated to use `self.env` (=the env created in the web controller) instead of `request.env` (=the missing env of the request). 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#107953 Forward-Port-Of: odoo/odoo#106676
task #2995601 PR https://github.com/odoo/enterprise/pull/33886 Description of the issue/feature this PR addresses: An option to disable the automatic wrapping of inline nodes in `<p>` elements at editable root is needed by Studio's report editor. Current behavior before PR: Inserting an inline block next to a regular block in Studio's report editor and then editing the block's content is does not work as expected (the text ceases to be inline). Desired behavior after PR is merged: I
Original PR description
task #2995601 PR https://github.com/odoo/enterprise/pull/33886 Description of the issue/feature this PR addresses: An option to disable the automatic wrapping of inline nodes in `<p>` elements at editable root is needed by Studio's report editor. Current behavior before PR: Inserting an inline block next to a regular block in Studio's report editor and then editing the block's content is does not work as expected (the text ceases to be inline). Desired behavior after PR is merged: Inline "blocks" in Studio's report editor works properly. Forward-Port-Of: odoo/odoo#105585
- Before this commit Keyboard navigation in dropdowns lead to a traceback - Explanation The traceback happens in the bootstrap library. When upgrading to bootstrap v5.1.3 (see c48f57e), a fix done in the previous bootstrap version was lost (see 78f85f2). This previous fix also added a test but it was not enough to detect the issue when the bootstrap lib was upgraded. - After this commit This commit reintroduce the same previous fix and adapts the test, hoping it would be enough for future chan
Original PR description
- Before this commit Keyboard navigation in dropdowns lead to a traceback - Explanation The traceback happens in the bootstrap library. When upgrading to bootstrap v5.1.3 (see c48f57e), a fix done in the previous bootstrap version was lost (see 78f85f2). This previous fix also added a test but it was not enough to detect the issue when the bootstrap lib was upgraded. - After this commit This commit reintroduce the same previous fix and adapts the test, hoping it would be enough for future changes to not break further the expected behavior. Forward-Port-Of: odoo/odoo#108031
When installing l10n_au, printing a PDF from any invoice will raise a UserError (this one: https://github.com/odoo/odoo/blob/16.0/odoo/addons/base/models/ir_actions_report.py#L699). Indeed, the content of the PDF is empty. Because no qweb report is called since on line https://github.com/odoo/odoo/blob/16.0/addons/account/views/report_invoice.xml#L335, the t-if is falsy. Indeed, the `o._get_name_invoice_report()` returns `l10n_au.report_invoice_document` since the l10n_au was made primary in
Original PR description
When installing l10n_au, printing a PDF from any invoice will raise a UserError (this one: https://github.com/odoo/odoo/blob/16.0/odoo/addons/base/models/ir_actions_report.py#L699). Indeed, the content of the PDF is empty. Because no qweb report is called since on line https://github.com/odoo/odoo/blob/16.0/addons/account/views/report_invoice.xml#L335, the t-if is falsy. Indeed, the `o._get_name_invoice_report()` returns `l10n_au.report_invoice_document` since the l10n_au was made primary in https://github.com/odoo/odoo/commit/5079ace74958d4acd54d24a95579289a2eda92f1. To solve that, we need to inherit the `report_invoice_with_payments` template in l10n_au, change the name in the `t-if` and call the `l10n_au` report. Forward-Port-Of: odoo/odoo#108040
Before this commit, the JS Framework receives different types of modifiers: - List: used for domains. - String: used for the dynamic domains and boolean values ('1' or '0'); - Integer: used for boolean values (1 or 0); - Boolean: used for boolean values (True or False); The issue with this, is that the JS Framework needed to manage the 3 different possibles ways to have a boolean modifier (1, '1', True). Now, only three types are sent to the JS Framework: - List: used for domains.
Original PR description
Before this commit, the JS Framework receives different types of modifiers:
- List: used for domains.
- String: used for the dynamic domains and boolean values ('1' or '0');
- Integer: used for boolean values (1 or 0);
- Boolean: used for boolean values (True or False);
The issue with this, is that the JS Framework needed to manage the 3
different possibles ways to have a boolean modifier (1, '1', True).
Now, only three types are sent to the JS Framework:
- List: used for domains.
- String: used for dynamic domains;
- Boolean: used for boolean values (True or False).
The boolean usually sent in a String ('1' or '0') or Number (1 or 0)
will be transformed into proper Boolean types (True or False).\
Note that, the 'falsy' modifiers are not sent to the JS Framework.
Forward-Port-Of: odoo/odoo#107959The currency field shows as a badly aligned "in USD". This PR adds a proper handling of the combinations of accounting and multi_currency groups. **Original PR in v15**: https://github.com/odoo/odoo/pull/104013 **Original behaviour (in v15)**:  **Combinations** (images for v16): Accountant, single currency ![image](https://user-images.githubusercontent.com/1665365/197804157
Original PR description
The currency field shows as a badly aligned "in USD". This PR adds a proper handling of the combinations of accounting and multi_currency groups. **Original PR in v15**:…
The currency field shows as a badly aligned "in USD". This PR adds a proper handling of the combinations of accounting and multi_currency groups. **Original PR in v15**: https://github.com/odoo/odoo/pull/104013 **Original behaviour (in v15)**:  **Combinations** (images for v16): Accountant, single currency  Accountant, multi currency  Billing, multi currency  Billing, single currency  Forward-Port-Of: odoo/odoo#108044 Forward-Port-Of: odoo/odoo#104814
Steps to reproduce: - edit some text on the website - select a part of the text then press (alt+s) Bug: the selected text is deleted before the save Fix: if "alt" key is pressed don't execute the editor listener opw-2996264 Forward-Port-Of: odoo/odoo#108059 Forward-Port-Of: odoo/odoo#106412
Original PR description
Steps to reproduce: - edit some text on the website - select a part of the text then press (alt+s) Bug: the selected text is deleted before the save Fix: if "alt" key is pressed don't execute the editor listener opw-2996264 Forward-Port-Of: odoo/odoo#108059 Forward-Port-Of: odoo/odoo#106412
Removed annoying error raised onchange of the date/name if they don't match anymore. This was done during the update, which was dumb since it was popping in case you wanted to change both the date and the name. It now only relies on the constraint that is verified upon posting the invoice. Onchange warning is kept only for the format change. Ensure the date constraint is always verified no matter if the invoice was already posted before, or if we're in quick edit mode: the date's info located
Original PR description
Removed annoying error raised onchange of the date/name if they don't match anymore. This was done during the update, which was dumb since it was popping in case you wanted to change both the date and the name. It now only relies on the constraint that is verified upon posting the invoice. Onchange warning is kept only for the format change. Ensure the date constraint is always verified no matter if the invoice was already posted before, or if we're in quick edit mode: the date's info located in the name must always match the accounting date. This is ensured when posted. task-2976499 Forward-Port-Of: odoo/odoo#107867
Sometimes, there is a crash when uploading a file when loading an article for the first time. Impacted versions: 16.0+ How to reproduce: - open the odoo home page (module menu) and CTRL+f5 (force reload) - go to the knowledge app - switch to another article than the first loaded one - in that article, put the cursor somewhere and type ENTER to create a new line - type the /file command in that line - try to upload a file - traceback (if it does not happen, try again fr
Original PR description
Sometimes, there is a crash when uploading a file when loading an article for the first time. Impacted versions: 16.0+ How to reproduce: - open the odoo home page (module menu) and CTRL+f5 (force…
Sometimes, there is a crash when uploading a file when loading an article for the first time. Impacted versions: 16.0+ How to reproduce: - open the odoo home page (module menu) and CTRL+f5 (force reload) - go to the knowledge app - switch to another article than the first loaded one - in that article, put the cursor somewhere and type ENTER to create a new line - type the /file command in that line - try to upload a file - traceback (if it does not happen, try again from the first step, it is not always consistent) Explanation: html_field onWillUpdateProps was using the wrong "new" values to update the currentEditingValue, which sometimes induced a rerendering of the html_field during a 'blur' event when it should not have (because it seemed that the value had changed when it did not), which could cause a crash when it occured after the editor saved nodes with `preserveCursor` to recover the cursor position. (i.e. when opening the mediaDialog to upload/select a file for insertion in the editor). Task-3086694 Forward-Port-Of: odoo/odoo#106912
Forward-Port-Of: odoo/enterprise#34999
Original PR description
Forward-Port-Of: odoo/enterprise#34999
Inserting an inline block next to a regular block in Studio's report editor and then editing the block's content is does not work as expected (the text ceases to be inline). This happens because web_editor wraps the content of this inline block in `<p>` tags. This behavior was introduced by a fix that wraps any inline nodes into a p (paragraph tag) at the root of the editable (see PR odoo/odoo #93207), and it's the Editor's default behavior. In order to disable this behavior in Studio's
Original PR description
Inserting an inline block next to a regular block in Studio's report editor and then editing the block's content is does not work as expected (the text ceases to be inline). This happens because web_editor wraps the content of this inline block in `<p>` tags. This behavior was introduced by a fix that wraps any inline nodes into a p (paragraph tag) at the root of the editable (see PR odoo/odoo #93207), and it's the Editor's default behavior. In order to disable this behavior in Studio's report editor, a new option was added to OdooEditor's options object. task #2995601 PR https://github.com/odoo/odoo/pull/105585 Forward-Port-Of: odoo/enterprise#33886
*: mail_mobile, web_dashboard, web_enterprise, web_studio Start odoo without -d and with a --dbfilter that allows multiple databases. Via JSON-RPC access the /web/session/authenticate route providing a non-filtered database and valid credentials. Traceback, `request.env` is None. Since httpocalypse the initialization of the ORM (cursor, registry, environment) is greedy. It means that the connection to the database is established very early during the request routing or skip altogether in c
Original PR description
*: mail_mobile, web_dashboard, web_enterprise, web_studio Start odoo without -d and with a --dbfilter that allows multiple databases. Via JSON-RPC access the /web/session/authenticate route providing…
*: mail_mobile, web_dashboard, web_enterprise, web_studio Start odoo without -d and with a --dbfilter that allows multiple databases. Via JSON-RPC access the /web/session/authenticate route providing a non-filtered database and valid credentials. Traceback, `request.env` is None. Since httpocalypse the initialization of the ORM (cursor, registry, environment) is greedy. It means that the connection to the database is established very early during the request routing or skip altogether in case no dbname was known at that time. This contrast with prepocalypse where the various ORM thingies were lazily setup the first time they were accessed. This changement has an important implication regarding authentication. In prepocalypse, thanks to the lazy approache, a cursor/registry/env would be setup on the database you just login upon using the `request.env` for the first time. This was very nice in this regard but had other problems. Since httpocalypse such operation is no more possible. Devs must initialize and use their own cursor/registry/env in case they authenticate on another database than the one `request.cr` is (maybe) connected to. The `/web/session/authenticate` controller is an example of such case. It crates its own cr/registry/environment after authentication. The problem the controller uses `ir.http.session_info` and that not all overrides were updated to use `self.env` (=the env created in the web controller) instead of `request.env` (=the missing env of the request). https://github.com/odoo/odoo/pull/106676 Forward-Port-Of: odoo/enterprise#34964 Forward-Port-Of: odoo/enterprise#34449
task - 2831024 Forward-Port-Of: odoo/enterprise#34994
Original PR description
task - 2831024 Forward-Port-Of: odoo/enterprise#34994
Since this [commit] the employee `work_email` and `mobile_phone` are stored in a separate `res.partner` record. When a user is linked to an employee, the partner related to both the employee and the user should be the same. When appraisal requests are created in the appraisal tests, the tests assume the name of the recipients equal those of the corresponding employees. However, a recipient is a partner, not an employee. More specifically it is the partner linked to the employee and to the associ
Original PR description
Since this [commit] the employee `work_email` and `mobile_phone` are stored in a separate `res.partner` record. When a user is linked to an employee, the partner related to both the employee and the user should be the same. When appraisal requests are created in the appraisal tests, the tests assume the name of the recipients equal those of the corresponding employees. However, a recipient is a partner, not an employee. More specifically it is the partner linked to the employee and to the associated user. As such the same names should be used when creating the users and their corresponding employees. opw-3031187 [commit]: https://github.com/odoo/odoo/commit/3c6060b7bbe9c67aca8073ef43c1e89fb7e820ca Forward-Port-Of: odoo/enterprise#33565
Install Studio, open Settings -> Users -> any user, click on the Studio button ``` File "/home/odoo/src/odoo/16.0/odoo/addons/base/models/ir_ui_view.py", line 2477, in get_views result['views'] = { File "/home/odoo/src/odoo/16.0/odoo/addons/base/models/ir_ui_view.py", line 2478, in <dictcomp> v_type: self.get_view( File "/home/odoo/src/odoo/16.0/odoo/addons/base/models/ir_ui_view.py", line 2665, in get_view node = self.env['ir.ui.view']._postprocess_access_rights(node)
Original PR description
Install Studio, open Settings -> Users -> any user, click on the Studio button
```
File "/home/odoo/src/odoo/16.0/odoo/addons/base/models/ir_ui_view.py", line 2477, in get_views
result['views'] = {
File "/home/odoo/src/odoo/16.0/odoo/addons/base/models/ir_ui_view.py", line 2478, in <dictcomp>
v_type: self.get_view(
File "/home/odoo/src/odoo/16.0/odoo/addons/base/models/ir_ui_view.py", line 2665, in get_view
node = self.env['ir.ui.view']._postprocess_access_rights(node)
File "/home/odoo/src/enterprise/16.0/web_studio/models/ir_ui_view.py", line 101, in _postprocess_access_rights
field = self.env[model]._fields[node.get('name')]
KeyError: 'in_group_12'
```
This issue happens because the model `res.users` implements fake field, which doesn't really exist in the model.
For those fields, we can assume they have no group on the Python definition of the field.
Forward-Port-Of: odoo/enterprise#34961Steps to reproduce: - Install data_merge & contacts modules - Go to Data Cleaning -> Deduplication - Add filter for field `Company` with operator `contains` Issue: Traceback raised. Cause: Search on company_id does not handle operators 'contains', 'doesn't contains', 'is equal' and 'is not equal'. (which related operators received by function will be 'ilike', 'not ilike', 'like' and not 'like'). Solution: This commit add the handling of the missings op
Original PR description
Steps to reproduce: - Install data_merge & contacts modules - Go to Data Cleaning -> Deduplication - Add filter for field `Company` with operator `contains` Issue: Traceback raised. Cause: Search on company_id does not handle operators 'contains', 'doesn't contains', 'is equal' and 'is not equal'. (which related operators received by function will be 'ilike', 'not ilike', 'like' and not 'like'). Solution: This commit add the handling of the missings operators. opw-3024851 Forward-Port-Of: odoo/enterprise#33678